Security

Advanced Load Balancing For Developers. The Network Dev Tool

Don MacVittie — Fri, 03 Feb 2012 18:54:59 GMT

It has been a while since I wrote an installment of Load Balancing for Developers, and now I think it has been too long, but never fear, this is the grad-daddy of Load Balancing for Developers blogs, covering a useful bit of information about Application Delivery Controllers that you might want to take advantage of. For those who have joined us since my last installment, feel free to check out the entire list of blog entries (along with related blog entries) here, though I assure you that this installment, like most of the others, does not require you to have read those that went before.

ZapNGo! Is still a growing enterprise, now with several dozen complex applications and a high availability architecture that spans datacenters and the cloud. While the organization relies upon its web properties to generate revenue, those properties have been going along fine with your Application Delivery Controller (ADC) architecture.

Now though, you’re seeing a need to centralize administration of a whole lot of functions. What worked fine separately for one or two applications is no longer working so well now that you have several development teams and several dozen applications, and you need to find a way to bring the growing inter-relationships under control before maintenance and hidden dependencies swamp you in a cascading mess of disruption.

With maintenance taking a growing portion of your application development manhours, and a reasonably well positioned test environment configured with a virtual ADC to mimic your production environment, all you need now is a way to cut those maintenance manhours and reduce the amount of repetitive work required to create or update an application. Particularly update an application, because that is a constant problem, where creating is less frequent.

With many of the threats that your ZapNGo application will be known as ZapNGone eliminated, now it is efficiencies you are after. And believe it or not, these too are available in an ADC. Not all ADC’s are created equal, but this discussion will stay on topics that most ADCs can handle, and I’ll mention it when I stray from generic into specific – which I will do in one case because only one vendor supports one of the tools you can use, but all of the others should be supported by whatever ADC vendor you have, though as always, check with your vendor directly first, since I’m not an expert in the inner workings of every one.

There is a lot that many organizations do for themselves, and the array of possibilities is long – from implementing load balancing in source code to security checks in the application, the boundaries of what is expected of developers are shaped by an organization, its history, and its chosen future direction. At ZapNGo, the team has implemented a virtual test environment that as close as possible mirrors production, so that code can be implemented and tested in the way it will be used. They use an ADC for load balancing, so that they don’t have to rewrite the same code over and over, and they have a policy of utilizing a familiar subset of ADC functionality on all applications that face the public.

The company is successful and growing, but as always happens in companies in that situation, the pressures upon them are changing just by virtue of their growth. There are more new people who don’t yet have intimate knowledge of the code base, network topology, security policies, whatever their area of expertise is. There are more lines of code to maintain, while new projects are being brought up at a more rapid pace and with higher priorities (I’ve twice lived through the “Everything is high priority? Well this is highest priority!” syndrome while working in IT. Thankfully, most companies grow out of that fast when it’s pointed out that if everything is priority #1, nothing is). Timelines to complete projects – be they new development, bug fixes, or enhancements are stretching longer and longer as the percentage of gurus in the company is down and the complexity of the code and the architecture it runs on is up.

So what is a development manager to do to increase productivity? Teaming newer developers with people who’ve been around since the beginning is helping, but those seasoned developers are a smaller and smaller percentage of the workforce, while the volume of work has slowly removed them from some of the many products now under management. Adopting coding standards and standardized libraries helps increase experience portability between projects, but doesn’t do enough.

Enter offloading to the ADC. Some things just don’t have to be done in code, and if they don’t have to be, at this stage in the company’s growth, IT management at ZapNGo (that’s you!) decides they won’t be. There just isn’t time for non-essential development anymore.

Utilizing a policy management tool and/or an Application Firewall on the ADC can improve security without increasing the code base, for example. And that shaves hours off of maintenance projects, while standardizing on one or a few implementations that are simply selected on the ADC. Implementing Web Application Acceleration protocols on the ADC means that less in-code optimization has to occur. Performance is no longer purely the role of developers (but of course it is still a concern. No Web Application Acceleration tool can make a loop that runs for five minutes run faster), they can allow the Web Application Acceleration tool to shrink the amount of data being sent to the users’ browser for you. Utilizing a WAN Optimization ADC tool to improve the performance of bulk copies or backups to a remote datacenter or cloud storage… The list goes on and on.

The key is that the ADC enables a lot of opportunities for App Dev to be more responsive to the needs of the organization by moving repetitive tasks to the ADC and standardizing them. And a heaping bonus is that it also does that for operations with a different subset of functionality, meaning one toolset gives both App Dev and Operations a bit more time out of their day for servicing important organizational needs. Some would say this is all part of DevOps, some would say it is not. I leave those discussions to others, all I care is that it can make your apps more secure, fast, and available, while cutting down on workload.

And if your ADC supports an SSL VPN, your developers can work from home when necessary. Or more likely, if your code is your IP, a subset of your developers can. Making ZapNGo more responsive, easier to maintain, and more adaptable to the changes coming next week/month/year. That’s what ADCs do. And they’re pretty darned good at it.

That brings us to the one bit that I have to caveat with F5 only, and that is iApps. An iApp is a constructed configuration tool that asks a few questions and then deploys all the bits necessary to set up an ADC for a particular application. Why do I mention it here? Well if you have dozens of applications with similar characteristics, you can create an iApp Template and use it to rapidly bring new applications or new instances of applications online. And since it is abstracted, these iApp templates can be designed such that AppDev, or even the business owner, is able to operate them Meaning less time worrying about what network resources will be available, how they’re configured, and waiting for operations to have time to implement them (in an advanced ADC that is being utilized to its maximum in a complex application environment, this can be hundreds of networking objects to configure – all encapsulated into a form). Less time on the project timeline, more time for the next project. Or for the post deployment party. One of the two. That’s it for the F5 only bit.

And knowing that all of these items are standardized means less things to get mis-configured, more surety that it will all work right the first time. As with all of these articles, that offers you the most important benefit… A good night’s sleep.

Technorati Tags: Application Delivery Controllers,VPN,Security,Applicaiton Development,Acceleration,WAN Optimization,Encryption,F5 Networks,Load Balancing For Developers,Don MacVittie,blog

Connect with Don:	Connect with F5:

Related Articles and Blogs

Like Cars on a Highway.

Don MacVittie — Tue, 31 Jan 2012 21:31:38 GMT

Every once in a while, as the number of people following me grows (thank you, each and every one), I like to revisit something that is fundamental to the high-tech industry but is often overlooked or not given the attention it deserves. This is one of those times, and the many-faceted nature of any application infrastructure is the topic. While much has changed since I last touched on this topic, much has not, leaving us in an odd inflection point. When referring to movies that involve a lot of CGI, my oldest son called it “the valley of expectations”, that point where you know what you’d like to see and you’re so very close to it, but the current offerings fall flat. He specifically said that the Final Fantasy movie was just such a production. The movie came so close to realism that it was disappointing because you could still tell the characters were all animations. I thought it was insightful, but still enjoyed the movie.

It is common to use the “weakest link in the chain” analogy whenever we discuss hardware, because you have parts sold by several vendors that include parts manufactured by several more vendors, making the entire infrastructure start to sound like the “weakest link” problem. Whether you’re discussing individual servers and their performance bottlenecks (which vary from year to year, depending upon what was most recently improved upon), or network infrastructures, which vary with a wide variety of factors including that server and its bottlenecks.

I think a better analogy is a busy freeway. My reasoning is simple, you have to worry about the manufacture and operation of each vehicle (device) on the road, the road (wire) itself, interchanges, road conditions, and toll booths. There is a lot going on in your infrastructure, and “weakest link in the chain” is not a detailed enough comparison.

In fact, if you’re of a mathematical bent, then the performance of your overall architecture could be summarized by the following equation:

Where n is the number of infrastructure elements required for the application to function correctly and deliver information to the end user. From databases to Internet connections to client bandwidth, it’s all jumbled up in there. Even this equation isn’t perfect, simply because some performance degradation is so bad that it drags down the entire system, and other issues are not obvious until the worst offender is fixed. This is the case in the iterative improvement of servers… Today the memory is the bottleneck, once it is fixed, then the next bottleneck is disk, once it is improved, the next bottleneck is network I/O… on and on it goes, and with each iteration we get faster overall servers.

And interestingly enough, security is very much the same equation, with the caveat that a subset of infrastructure elements is likely to be looked at for security, just because not everything is exposed to the outside world – for example, the database only need be considered if you allow users to enter data into forms that will power a DB query directly.

So what is my point? well simply put, when you are budgeting, items that impact more than one element – from a security or performance perspective – or more than one application, should be prioritized over things that are specific to one element or one application. The goal of improving the overall architecture should trump the needs of individual pieces or applications, because IT – indeed, the business – is built upon the overall application delivery architecture, not just a single application. Even though one application may indeed be more relevant to the business (I can’t imagine that eBay has any application more important than their web presence, for example, since it is their revenue generation tool), overall improvements will help that application and your other applications.

Of course you should fix those terribly glaring issues with either of these topics that are slowing the entire system down or compromising overall security, but you should also consider solutions that will net you more than a single-item fix.

<blatant marketing>Yes, I think an advanced ADC product like F5’s BIG-IP is one of these multi-solution products, but it goes well beyond F5 into areas like SSDs for database caches and such. </blatant marketing>

So keep it in mind. Sometimes the solution to making application X faster or more secure is to make the entire infrastructure faster or more secure. And if you look at it right, availability fits into this space too. Pretty easily in fact.

Technorati Tags: Performance,Security,Architecture,Server,F5 BIG-IP,F5 Networks,Don MacVittie,Blog

Connect with Don:	Connect with F5:

Related Articles and Blogs:

Blitzkrieg and VDI Edge Protection.

Don MacVittie — Thu, 26 Jan 2012 21:19:26 GMT

By now, everyone even vaguely familiar with information security knows the military maxim of blitzkrieg – burst through the hardened defense at a single point and then rush pell-mell to the rear where the soft underbelly of any static army lies. It is a good military strategy, provided you have the resources to break through the defenses and follow up with a rapid advance into the rear areas. While there are variants of this plan, and a lot of discussion about how/when it is strategically worth the risk, historically speaking it has been a smashing success. Germany did it to France and the Low Countries in 1940, to Russia in 1941, Russia returned the favor in 1943, and the western allies joined used it successfully at Normandy in late 1944. Sherman’s March to the Sea in the American Civil War was just such a ploy (though Sherman was more willing to hit civilian targets than a 20th century general would have been, it was still a rush to the soft rear), and the first Gulf War had the coalition forces doing much the same. These are just the large-scale instances of this theory in operation, but you have to admit it works. The risk is high though, as the Germans found out at Prokhorovka, and that alone makes generals cautious that they have the resources and intelligence reports to burst through in the first place.

The difference between the military maxim and the theory that information security should follow it is an important one. In military theory, you only harden behind the lines if there is a high likelihood that the enemy forces will find a weak spot in your lines and exploit it to get at the rear areas. The conundrum for the defensive leader finding themselves in such a situation is that every combat soldier placed to the rear is one less combat soldier on the front, increasing the likelihood that there will be a breakthrough. In information security, the problem is that the resources of the attacker are theoretically unlimited. Unless they are apprehended by the authorities in their home country, there is no penalty for attacking over and over and over. The limiting factor for the attacker – that they might smash themselves upon their opponent – does not exist at this time in Internet parlance. An attack fails, that merely means the attacker marshals the same exact set of resources and tries again.

The defense, on the other hand, still has a limited number of resources (dollars and staff hours) to defend themselves with. And they must make the most of them. Defense in depth is an absolute necessity, simply because the attacker can continue ad-infinitum to try attacking, and the number of attackers is unknown but large. That leaves a heavy burden on information security staff, who have settled into the glum belief that it is “not if, but when” they will be defeated. While the ultimate solution to this problem rests outside the purview of corporate security, in the interim, it is necessary to do what can be done to simplify and strengthen the fortifications that are between ne’er do wells and corporate resources.

Just to add fuel to the fire, this is all happening at the same time that organizations are facing increasing pressure to expose more and more of their internal architecture to the Internet so that users can access their applications from essentially anywhere. So to put it into military terms, there are numerous hostile entities, an ever increasing front length, and a static number of defenders and resources. That is not a recipe for success in most scenarios.

So what is the serious information security professional to do? Well the first steps have already been taken. Defense in depth is just a fact that most organizations live with, down to firewalls between departments for some organizations. Anti-virus tools and encryption are the norm, not the exception, and external access is generally protected by a VPN. But new technologies bring new challenges, or more frequently make old but low likelihood challenges into higher priority issues.

As we deploy VDI – and we are deploying VDI at a faster rate than I’d expected – the issue of edge security becomes more and more of an issue. If you expose VDI desktops to the world so that your workers can log in at any hour and get some work done, or an employee who’s sick can stay home to avoid infecting others but is well enough to work can do so, you will have to find a way to lock that interface to the world down so that users can get in, but hackers cannot. This is more important than most interfaces because the interface sits in front of user desktops, and they generally have more access than a server.

While there are a variety of ways to attack such an inlet, DDoS – to keep employees from working remotely – and Trojans are the two most likely to be successful. What you’ll want on this inlet is a way to check that the client – be it PC or iPad or whatever – complies with security policy that includes at least rudimentary virus checking (since the client device is outside your network and possibly not even a corporate resource), and a way to resist DDoS attacks. A network level tool that shunts detected DDoS attacks off to neverland, like F5’s own BIG-IP is going to be the best solution, since traditional firewalls are aimed at detecting more traditional attacks and can become victims of a DDoS. Regardless of what you choose to protect against this type of attack, it should be something you can guarantee will stay standing when hit with thousands of dropped connections a second.

And you’ll want to be able to apply more generally corporate security policies. That’s a tough call in a VDI environment. While a product like BIG-IP can be set up to use your corporate security policies for access and authentication purposes, it is difficult – both legally and technologically - to force corporate security policy on employee-owned devices. Legally you can limit access based upon the status of the machine requesting it, the user name, and the geographic location, but you can’t insure that the device meets with the same stringent policies you would require on your internal network. And that’s a problem, because VDI is your internal network. Time will tell how large this threat looms, but I wouldn’t ignore it, since we know it’s a threat. Legally you can ask employees to agree to be bound by corporate security policy when accessing the corporate network from a home machine, but I honestly don’t know of anyone doing that today – and I am not a lawyer, so maybe there’s a good legal reason I haven’t heard of anyone doing just that.

In the end, the benefits of allowing some or all users to access their desktop remotely is a huge benefit, but be careful out there, the number of attackers isn’t going down, and while we’re working all of this out is their opportunity to take advantage of weaknesses. So protect yourself. I’d recommend F5 products, but there are other ways to try and resist the hoards should they come knocking at your public VDI interface. Whatever you choose, just make certain it is implemented well.

Technorati Tags: Information Security,VDI,Defense In Depth,DDoS,iPad,F5 Networks,Don MacVittie

Connect with Don:	Connect with F5:

Related Articles and Blogs:

New Year, Fewer Predictions

Don MacVittie — Tue, 10 Jan 2012 16:20:40 GMT

After a couple of weeks of vacation, some minor oral surgery, a birthday, and my five year anniversary at F5 Networks (has it really been that long?), I’m back to annoy or please you some more. Our holidays were acceptable, and here’s hoping all of you had an enjoyable time also.

One thing I noticed is either that I was out of touch over vacation, or there were far fewer “tech predictions for 2012” type articles than has been the case in the past. I think that’s a good thing. Let’s just deal with things as they come, shall we? We’ve got a ton of new technology covering everything from Security to Storage and every vertical you can think of, and there needs to be a bit of a breather while it’s all figured out.

What I didn’t see that I missed though was some talk about what happened in Tech that was big last year. I know F5 had some pretty big announcements – from I Am Chaos, talking about datacenter security, to heterogeneous virtualization, the gang here has been rolling along, makes me wonder what the pundits thought were the really cool tech (not consumer) things of 2011. Partially because I would hope that some of our cool items like deploying and configuring network resources in 10% of the time it traditionally takes (using iApps) would be on the list, partially because if they’re not, imagine how cool the things that are on the list must be. I like to hear what others thought was cool, if for no other reason than to scan the list and see what might have flown under my radar.

Cloud Computing, no doubt, would be on the list, though I think the industry still struggling with what exactly cloud is. Platform As A Service? Software As A Service? Virtualization With Network Elements? Whatever The Heck You Want It To Be? :-). We’ll figure it out, but meanwhile, success stories are starting to come in, which is good. Doesn’t matter how “hot” a technology is, companies are slow to bet their entire business on them before others say “hey! we used it for X and it worked really well!” and technologies to help IT get control in-the-cloud at a level closer to their datacenter control are coming around. We were in that group of cool new things.

No doubt the whole App Store thing would be on there. Tech companies hopped on that bandwagon hard in 2011, and you can get apps to do all sorts of important IT functions these days. We have an app for our VPN product now too, and other companies have gone farther than F5 has. The interesting thing about discussing “app store” as an entity is that Apps like our VPN client for Android are being discussed in the same phrase as games like Defender. That’ll have to sort itself out a bit, of course more people are going to download a free game that works on any Android platform than are going to download a free tool that is only useful if you have specialized hardware. And Angry Birds? Yeah. Enough said.

The relative silence of Microsoft should be making the list too. They’ve been a force to be reckoned with for well over a decade, but in 2011 they were relatively quiet. I don’t expect that to run into 2012, but it did give some smaller (and larger) competitors a chance to breath a little and get their voices heard in several market spaces. That’s not to say Microsoft was silent, but the normal cycle of “let’s mention Microsoft in every datacenter-relevant article” and “there’s another Microsoft advertisement” didn’t seem to be so prevalent.

The increasing use of Internet video by consumers should be on there. This is not a consumer list or we’d have to go into new iPhones and tablets and all of that, but the traffic generated by video is much larger than the traffic generated by other forms of content, and seriously, at one of our houses we have no cable-style connections at all. We watch TV with a Roku and fiber optics. Isn’t the 21st century grand? It is, but there’s a limit to how far we can push the volume through the Internet. And while I’ve never been one of the “XML will burn up the Internet” crowd, it will be interesting to see how much we can slam through in video before performance starts to degrade more generally. Looking at YouTube and the volume they handle over their limited Internet connections, I’m guessing we’re nowhere close to performance degradation overall.

And of course Diverse Distributed DoS – or 3DoS as Lori calls it – must be on the list. It caused all of us to pause and rethink the overlap of security and availability. It certainly helped us decide that BIG-IP, correctly configured, could protect your datacenter. When the attack is too much for a standard firewall to handle, it’s good to have a piece of hardware whose purpose is to handle high-volume traffic and can detect this type of attack. That’s not to mention the changing attitudes about security that a veritable wave of leaks produced.

That’s five. They’re not tied to products, but to events. No doubt I missed some important ones, but it was an interesting year. 2012 holds promise of being just as exciting. I can’t speak for you, but I’m happy to ride along and see what they are. Some of the things we announced late in 2011 promise to bring huge benefits to our customers in 2012, so both from a more general and an employer-specific perspective I’m thrilled to see 2012.

And it’s all getting better. There’s a poll out today that Lori forwarded to our team – 46% of Americans think tablets will replace computers. I know I use my Android tablet for a lot more than I expected to when she bought it for me, just a few months ago, so maybe they’re right. But I doubt it will be in 2012, there’s still a lot that I head to the computer for.

Anyway, thought I’d welcome you all to 2012, and say “I’m Baaaaaaaaaack!”

Technorati Tags: Cloud Computing,App Store,Microsoft,Streaming Video,3DoS,2012,2011,tablet PCs,F5 Networks,F5 iApps,Don MacVittie

Connect with Don:	Connect with F5:

Related Articles and Blogs:

From Point A to Point B.

Don MacVittie — Tue, 13 Dec 2011 19:13:19 GMT

The complexities of life often escape a young child. The Little Man asked me the other day why I had to go work, which was both a compliment to wanting to spend time with me and an unintended backhand slap at Lori, who was going to hang out with him while I took care of business. The answer was the usual stuff, that working paid the bills, and work has its own rewards… It did not include “and I like my job”, though I do, simply because I didn’t want to imply “more than hanging out with you” to a three year old.

But children boil everything down to simplicity. The picture over there is said son, wearing a picklehaube with a Transformers shirt and (yes really) proclaiming he was an autobot because of the helmet.

We adults, on the other hand, tend to layer complexity upon complexity until we’re not certain we’re getting value anymore, but we’re proud of whatever it is we have done/built/know. IT is like that sometimes. What is “the network” – in tweet length, for example?

Not only is the answer tough to cram into tweet length, it is tougher to cram into tweet length and make useful. It is even more difficult to cram it into tweet length and include all the various constituencies of IT in the answer.

But it can be done, because a “network” is a simple concept. You’re moving information from point A to point B. That’s it. Everything else is layers we’ve added over it to make some aspect of that movement better, or to facilitate the movement of data. But in the end, it is just sending bytes over the wire. If, for example, a business person with no IT background asks why a whole section of the corporate network is down, they don’t care about routing tables or even DNS, they care about “The network broke, and those clients can’t get to the datacenter. The network is complex, but we’ll have it up soon.”

If you’re moving data over the WAN, it gets another layer of complexity – because you want to move data over the WAN at a decent speed, but most applications aren’t designed for network communication optimization. Instead they’re designed to be very good at moving data, and expect the network to worry about performance issues. But business users don’t want to hear about compression, dedupe, SSL offload, or any of that when things go wrong, they want to hear “The copy of our data at the remote site is a little out of synch right now, but we’re on it, and it will all be fine soon.”

Want to secure the network? BAM! Another complex layer is tossed on top of that – but the point is that you don’t just want to move data from point A to point B anymore, you want to move data from point A to point B securely. Again, if your ADS or LDAP system goes on the fritz, you’re going to want to be able to tell people “users can’t log in right now, the servers that know who can do what are offline, but we’ll have them back up soon.” because users care that data isn’t moving from point A to point B, not about whatever bugbear has cropped up with authentication or the network.

Want to give web users – internal and external – an enhanced experience while reducing the load on your servers? Another layer of complexity piles on, as you use Web Application Optimization techniques. They work great – at least those by F5 do, since I’ve been a user of them – but they add a whole new layer of oddities. “No, the new logo isn’t showing reliably, but the team is flushing the cache and/or changing the expiration date to get that fixed, and it’ll be right soon.” is what business users want to hear.

Load balancing to increase reliability and performance adds yet another layer of complexity to the overall system, a layer that has all of its own terminology. But when load balancing goes wrong, “We misconfigured the Virtual IP and the Pool it points to does not serve your app” isn’t what the business person wants to hear. “Yes, we had an error, but your application should be back online soon.” is the right answer.

Server virtualization doesn’t directly add complexity to the network, but server sprawl certainly does because now there are a lot more clients out there. One of the early problems with server sprawl that seems to be largely defeated was “where is that non-responding virtual running again?” But still, if the hardware goes down that a users’ VM is running on, they want to hear “Yes, we had a hardware failure, but your application should be back up on another server soon, and we’ll get the problem fixed then move your application back.”

Desktop virtualization adds both complexity and traffic to your network, but simplifies a whole array of things from desktop management to licensing. Still, when it is performing poorly, a business leader does not want to hear about oversubscription, congestion, or the number of VMs per server, or anything else technical, they want to hear “Yes, we see that performance is down for those users. We’ve got a plan to fix it, and all should be back to normal soon.”

The thing is, F5 sells tools to help with all of these issues. In fact, F5 sells a platform that you can customize to help with all of these issues… But notice that all the answers to business are simple, and end with "some variant of “back up soon”? We can supply you with tools to manage the “back up soon” or even make you able to say “there was a problem, but you shouldn’t have noticed”, we cannot provide you with a tool to make everything simple. The business sometimes needs educating, but most of the time they just need less detail and more information.

We’ve got a ton of cool stuff going on in IT these days, but sometimes the complexity masks the simplicity. Boil it down to the basics, and tackle real problems. And enjoy talking simplicity for a change... Because the next round of Buzzword Bingo is on its way in 5,4,3,2,1…

Technorati Tags: WAN Optimization,Web Acceleration,Security,virtualization,VDI,Authentication,F5 Networks,Don MacVittie

Connect with Don:	Connect with F5:

Related Articles and Blogs

He Who Defends Everything Defends nothing… Right?

Don MacVittie — Tue, 22 Nov 2011 21:13:41 GMT

There has been much made in Information Technology about the military quote: “He Who Defends Everything Defends Nothing” – Originally uttered by Frederick The Great of Prussia. He has some other great quotes, check them out when you have a moment. The thing is that he was absolutely correct in a military or political context. You cannot defend every inch of ground or even the extent of a very long front with a limited supply of troops. You also cannot refuse to negotiate on all points in the political arena. The nature of modern representative government is such that the important things must be defended and the less important offered up in trade for getting other things you want or need. In both situations, demanding that everything be saved results in nothing being saved. Militarily because you will be defeated piecemeal with your troops spread out, and politically because your opponent has no reason to negotiate with you if you are not willing to give on any issue at all.

But in high tech, things are a little more complex. That phrase is most often uttered to refer to defense against hacking attempts, and on the surface seems to fit well. But with examination, it does not suit the high-tech scenario at all. While defense in depth is important in datacenter defense, just in case someone penetrates your outer defenses. But we all know that there are one or two key choke-points that allow you to stop intruders who do not have inside help – your Internet connections. If those are adequately protected, the chances of your network being infiltrated, your website taken down, or any of a million other ugly outcomes are much smaller.

The problem, in the 21st century, is the definition of “adequate”. Recent attacks have taken down firewalls previously assumed to be “adequate”, and the last several years have seen a couple of spectacular DNS vulnerabilities focusing on a primary function that had seriously seen little attention from attackers or security folks. In short, the entire face you present to the world is susceptible to attack. And at the application layer, attacks can slip through your outer defenses pretty easily.

That’s why the future network defensive point for the datacenter will be a full proxy at the Strategic Point of Control where your network connects to the Internet. Keeping attacks from dropping your network requires a high-speed connection in front of all available resources. The Wikileaks attacks took out a few more than “adequate” firewalls, while the DNS vulnerabilities attacked DNS through its own protocol. A device in the strategic point of control between the Internet and your valuable resources needs to be able handle high-volume attacks and be resilient enough to respond to new threats be they at the protocol or application layers.

It needs to be intelligent enough to compare user/device against known access allowances and quarantine the user appropriately if things appear fishy. It also needs to be adaptable enough to adapt to new attacks before they overwhelm the network. Zero day attacks by definition almost never have canned fixes available, so waiting for your provider to plug the hole is a delay that you might not be able to afford.

That requires the ability for you to work in fixes and an environment that encourages the sharing of fixes – like DevCentral or a similar site. So that you can quickly solve the problem either by identifying the problem and creating a fix, or by downloading someone else’s fix and installing it. While an “official” solution might follow, and eventually the app will get patched, you are protected in the interim.

You can defend everything by placing the correct tool at the correct location. You can manage who has access to what, from which devices, when, and how they authenticate. All while protecting against DOS attacks that cripple some infrastructures. That’s the direction IT needs to head. We spend far too many resources and far too much brainpower on defending rather than enabling. Time to get off the merry-go-round, or at least slow it down enough that you can return your focus to enabling the business and worry less about security. Don’t expect security concerns will ever go away though, because we can – and by the nature of the threats must – defend everything.

Technorati Tags: Security,Strategic Points of Control,Full Proxy,F5 BIG-IP,F5 Networks,Don MacVittie,blog

Connect with Don:	Connect with F5:

Related Articles and Blogs:

The Past Is History, The Future A Chance To Do It Right.

Don MacVittie — Thu, 27 Oct 2011 18:57:31 GMT

There are many things in the history of high technology that are downright conundrums. One of the obvious ones is: given the formats and media currently used to distribute text, music, and video, for example, how do we protect the rights of both legal users and the creators of content? Of course we want people to be able to make a living of creating content, which does imply it is not given away at the whim of anyone with a copy, but we also (at least in most modern countries) want to protect the rights of people who have purchased (oh fine, licensed if you prefer) the software/book/music/movie to use their purchase/license freely. There isn’t an easy answer to this problem, because people disagree on the nature of the problem, and existing technology doesn’t support a reasonably sound mechanism for determining on-the-fly if the usage is legal.

We suffer a similar conundrum in InfoSec. We need to prevent unauthorized access to an application while not unduly inhibiting authorized access. The problem lies in the definition of “unauthorized”, which changes with every given application, and is wildly different between two points on the Internet. For some government websites, for example, “unauthorized” is, well, nearly everyone in the world. For other government websites, “unauthorized” is either a tiny subset of the world population, or only those who are set on disrupting the website’s normal function. The rest of the problem lies with the definition of “unduly inhibiting”. For most websites, “unduly inhibiting” is anything beyond a simple login. Indeed, for most websites out there, even logging in is delayed as long as possible. You can fill a cart in most web stores and only log in when going to check out, for example. But for some websites, again going to the government for examples (though there are plenty in the commercial world also), a physical security token with a login and a verification of ID are not “unduly inhibiting”, because the nature of the information to be found on the site is that sensitive.

We have traditionally protected our networks with firewalls, utilizing rules of these stalwart protectors between your application and the world to limit who can even get to an application. But firewalls were never a perfect solution. Logging in, for example, is not a function of a firewall for a given application, the application must handle this process. For known vulnerabilities, firewalls with advanced features are able to protect your application in the manner that all others are protected. They do a stand-up job of keeping malcontents at bay, in the generic 90% sense of “stand-up job”. But even modern “Application Layer” firewalls are not “Application Aware”. When they say “Application Layer”, they mean in the network stack, which is standards like TCP and HTTP, not actual Application needs.

But every application has its oddities. Be they the login process or the networks you want to allow connectivity to, be they protecting sensitive data from traversing the Internet unencrypted, or protecting a given field on a web page from various attacks that you know it is vulnerable to. And firewalls aren’t real good at most of these issues if they are issues for only your one application. Indeed, since firewalls are centralized to make management easier, most firewall products become unruly if you do use them to protect for the application-specific things that you know are out there.

A wonderful thing about history though, is that we write it forward. The future is coming, and we have the opportunity to make up for the shortcomings of traditional firewalls. We can “fill the gaps” so-to-speak with Web Application Firewalls. These tools are designed to protect your application and your application specifically from attacks that are more specific than the firewall would normally prevent. Utilizing application profiles (or templates, or whatever your vendor of choice calls them), you can start with generic settings for applications of the category yours is – or in many purchased-product cases the specific product. MS Exchange has enough organizations utilizing OWA for example, that most web application firewalls offer a canned OWA solution that you can then customize. Giving you protection specific to the application is a far site better than the generic protections you’ve gotten in the past. Many places have put Web Application Firewalls into place, but aren’t really using them for anything other than to check the box that says “requires a web application firewall” in a standard or regulation. That’s not making efficient usage of the tools at hand.

And there’s another reason that focusing security on applications is going to be important in the future. One you really do need to think about if you aren’t already pursuing this approach. Due to the nature of cloud computing, as I’ve mentioned before, your firewall, and all of your rules created over years of experience, is not going to run in a cloud. At least not right now. Some cloud vendors offer firewall services, but if you have a product like F5’s Application Security Manager (ASM), you can use the same rules in the physical version inside your datacenter and in the virtual edition running in a cloud environment. That’s a big bonus, as it allows you to copy your existing configuration, and with minimal changes to reflect the change in infrastructure, apply them to the virtual edition in the cloud. Your application receives the same exact protection, regardless of where future needs direct you to deploy it.

At least with InfoSec, we are making progress toward solving the problems. Now if only we could do so in the piracy space. Perhaps one day, we’ll have a way, and all agree on what is reasonable. Or at least most of us. Billions of people are highly unlikely to all agree.

Connect with Don:	Connect with F5:

Related Articles and Blogs

Even the best written code has a weakness.

Don MacVittie — Tue, 18 Oct 2011 20:04:59 GMT

Developers are a great lot of folks, people who spend their day trying to do the impossible with bits for a customer base that is, by and large, impossible to satisfy. When the bits all line up correctly, the last line of code has been checked in, and the nightly compile accepted for deployment, then they get to sit back, relax for five minutes, and start over again. If this makes you think it’s not a great life, then you should live it. Developing gives instant feedback. No matter how unhappy users can be, fixing that nagging bug you’ve been chasing for hours is a rush, and starting with a blank source code file is like looking across a wide-open plain. You can see what might be, and you get to go figure out how to do it.

But yeah, it’s high-stress. Deadlines are constant, and it’s not like writing where you have to get your content finished, once the code is done, ten million people want to have input into what you should have done. Various techniques have been developed to mitigate the depressing fact that people tell you what they want after they see what you’ve built, but the fact is, for most ordinary users, be they business users or end users, they don’t know what they want until they see something working on their monitor and can play with it. Because they need a point of comparison. Some few can tell you sight-unseen, early in the process, what they’d like, but most will have increasing demands as the application’s capabilities increase.

And these days, there’s one more major gotcha.

You have to care about the network. I’ve been saying that for years, but we’ve passed the point where you could ignore me.

Some will say “cloud changes all that!” but the truth is, cloud changes the problem domain, not the fact that you have to care.

Let’s say you have a web application (as there are precious few other types being developed these days), and you have tweaked it to uber-performance so that it is scalable. You’ve put it behind a load balancer or application delivery controller so that even if your tweaks aren’t enough, you can share the load amongst several copies. You’ve done it all right.

And your primary Internet connection goes down. So your network staff switches to the backup connection – which is invariably smaller than the primary.

The problem in this scenario is that your application can be load balanced and highly optimized, but now it is fighting for bandwidth on a reduced connection.

This is hardly the only scenario in which your application can suffer from outside interference. Ever been on the receiving end of a router configuration error? Your application appears down to everyone in the multi-verse, but in reality, it is responding just peachy but the network is routing your users to Timbuktu.

I could tell you about all the great solutions that F5 offers for this problem or that problem (there are many of them, and they’re pretty darned good), but from your perspective, the issue is (or should be) much bigger than that. You need to be able to understand when the problem at hand is a network problem, and you need to be able to diagnose that fact quickly, so the right people are on the job.

And that means you need to know networking. Just as importantly, you need to at least viscerally understand your specific network environment. They’re all a bit different, and the likely pain points are different, even though some problems are universal. A DDOS attack, for example, is aimed at clogging your Internet connection, no matter your architecture… But some networking gear reduces the ability of DDOS to actually take the site down, so your network might only see degraded performance.

So ask the network team to teach you. Ask them what devices are between your applications and your customers. Ask them how these devices (or their malfunction) impact your applications. Know the environment you’re in, because for most applications today, a problem on the network makes for a poorly performing application. And that is indeed your responsibility.

In the cloud you can’t know all of these things for real, but you can understand the concepts. Is there a virtual ADC? What is being used for firewall services? What perf tools are available to determine the bottlenecks of applications deployed in the cloud? All things you’ll want to know, so you can know how best to start troubleshooting when the inevitable problems occur. Learning things like this after your application is the source of user pain seems to still be the norm, but it’s certainly not the best solution. Either it increases the amount of time your application is getting bad PR, or you are fixing things hastily, and haste does indeed make waste in most critical application situations.

This knowledge will also give you a new set of tools to solve problems with. If you know that a Web Application Acceleration tool like F5’s WebAccelerator is in place between your application and the user, then you might be able to say “rather than rewrite this chunk of code, let’s tweak the Web Application Acceleration engine to handle it” and save both time and potential coding defect issues.

It’s still a great time to be a developer, the fun is still all there, it’s just a more complex world. Master your network architecture, and be a better developer for it.

Technorati Tags: AppDev,Web Applications,Load Balacing,Cloud,ADCs for Developers,F5 BIG-IP LTM,F5 WAM,F5 Networks,Don MacVittie

Connect with Don:	Connect with F5:

IT is not Ala Carte’. Or is it?

Don MacVittie — Tue, 11 Oct 2011 20:27:08 GMT

There has been a lot written about “IT Democratization” and how it will change the world. To some extent that is true, and I’ve previously encouraged IT management to support the process. But listening to those who see a “Bright new future” makes me realize that while we agree in principal, as always, the devil is in the details. In high school, we could take the standard lunch for a set fee or eat ala-carte’, which was essentially a short-order grill. Others could bring their own lunch, whatever they (or their parents) could pack into a bag or box.

In the case of ala carte’, the school had to plan ahead, make facilities ready, and be prepared to serve up quality food at affordable prices that would meet the whims of hundreds of high-school kids on any given day. A work of art that surely deserved more recognition than we gave it. In the case of bag lunches, well, the school provided nothing but tables. If the food was bad, ill-prepared, not suitable for human consumption, or otherwise not correct, this was not the school’s problem in any way.

The thing is that it was far easier for the school to eliminate all responsibility for the food and let children bring their own, no need to maintain the kitchens, stock food, suffer safety inspections, etc. The flip side of that is of course that the school has no ability to insure the quality of the food being consumed either. Ala-Carte’ was the best solution. Children got a choice, but the school got some say in what was prepared. It was not “that piece of salami that sat out all day Sunday for uncle Herb’s party” slapped into a sandwich.

And IT needs to come to the same realization… And guide business to that realization. Accepting connections from a variety of devices, even customizing content to meet the needs of some devices is fine, but removing all constraints makes security and quality assurance nearly impossible. There are some great tools out there – like our BIG-IP Access Policy Manager that will help your systems support a growing array of products, but you will still have to do the testing. Or customers/employees will, if your organization is of that mindset. And even then, these devices do not support every possible combination or do anything to insure the user experience is better than those bag lunches some people brought to school.

The key here, is that IT Democratization cannot become a call to a chaotic “bring whatever you have” bag-lunch style arrangement, simply because what is being consumed is company property on company servers, and what stands to be wasted is company resources. You need to approach the problem from “we need to expand support, what can we offer” not either of the two extremes that seem prevalent at the moment. Of course users will push for more, that’s part of what they do. But IT is responsible for security and usability of IT systems, so there has to be an acknowledgement of user desires meeting with the requirements of corporate data and systems needs.

And you have to drive that conversation. Certainly IT management, but anyone in IT that deals regularly with the rest of the company needs to reiterate the same thing… That IT wants to meet the needs of the organization, and user desires are certainly part of that, but security and usability require that the roll-out be controlled, so users need to prioritize what devices are most important to them to guide IT in its implementations. And IT needs to do the research. There is a growing industry offering all sorts of solutions for right-sizing content, along with the industry to extend enterprise-grade security to portable devices, and even specialized acceleration tools for low bandwidth devices. You just have to find the tools that best suit your needs and use them to enable users.

Is it possible that all of this is a fad? Yes possible, but not likely. The first thing everyone does on new gadgets is games, so there are a lot of people out there saying they game on their iPad and work on their laptop, but not everyone is saying that. We have three tablet PCs (Samsung and two RIM), and mostly we game on them at the moment, but we also work from them when our situation makes that more convenient than one of the many laptops strategically placed about the house. No doubt the ratio will tip as time goes on, and some are already talking about ditching their laptops.

So enable, but use the fact that you’re enabling to control the flood. Each new gadget that comes out does not need IT support. Some do, some don’t. Make certain your users know you are there to support them, but doing so in the manner that will work best for the organization.

And if you don’t have some form of tablet PC yet, play with one. Seriously. They’re a different experience, and you’ll understand why your users want support for them yesterday.

Technorati Tags: Dynamic Infrastructure,Democratization of IT,iPad,Playbook,Galaxy-Tab,Security,IT Management,blog,F5 APM,F5 Networks,Don MacVittie

Connect with Don:	Connect with F5:

Related Articles and Blogs

From Fort to Trade Network. IT Exposure Issues.

Don MacVittie — Tue, 13 Sep 2011 19:30:03 GMT

In most fantasy RPGs and in historical context, a fort is a well built defensive position that allows you to detect attacks and funnel them to places where they can be defeated. It's well constructed, has restricted points of entry, and has defense in depth. A trade network on the other hand is a lengthy line of trails and/or roads with little protection and lots of wide open spaces that allow enemies to attack at a point of their choosing.

IT is in a state of transformation that these two definitions fit rather well. It started with CDNs, continued with SaaS, and has been evolving ever since.

Prior to CDNs, IT datacenters were the fort. They had limited points of entry, firewalls protecting those points, and in a well designed datacenter, significant defense in depth. It didn't stop all attacks, but just as not all forts - from dirt berms to castles - are created equal and many fell while others withstood countless attacks, the same was true of datacenters. Most were not readily penetrated, and those that were usually stopped the assault quickly.

But with the growing footprint of the systems that used to be protected within the datacenter, our IT is increasingly looking more like a trade network than a lair. Long stretches of space separating variously defended groupings of applications.

In short, as we've grown where we deploy things, we have increased the attack vectors that ne'er-do-wells have against us. And for most IT shops, that is a problem that is only now being addressed.

What we need - really need - is a system that allows us to set all security policies for the datacenter, the cloud, and even in some cases for SaaS and CDN from a centralized location. We need to be able to say "our applications and the networks they run on are protected in a consistent manner no matter where they are deployed." That's a tall order. Since security is distributed across the application domain, network domain, and database/storage domain, it is a tough problem to resolve, but one we must.

To be able to set security policy at the datacenter and say "I don't care where it's deployed, this is the security system", whether we're talking about DDoS or XML injection, is growing imperative.

Of course F5 has products that will take you a long way down that path, but there are still a lot of variables to manage. If your cloud provider allows you to deploy VMs, most of the relevant F5 products are available in the cloud. For CDN and SaaS, my understanding is that you'll have to ask your vendor what is available, though both are slowly moving in a cloudy direction, so maybe that's only a short-term issue.

To be able to say "User X has access to application Y, no matter where user X is coming from, but only on devices that meet criteria "A, B, and C" is a highly granular security mechanism that helps in the application realm. To be able to say "Automatically detect DDoS attacks and reject them" is another in the networking realm. Soon you start to see a small configuration of issues that need to be extended out to the cloud, and if done so with a minimum of fuss (there is a whole lot assumed by both of these - ability to access user info from the cloud in the first one and ability to detect multiple forms of DDoS in the second for starters), can make your trade network into a series of fortifications connected by a unified strategy for dealing with intruders.

I much prefer to keep fortifications and the need to defend against ne'er-do-wells in my gaming, but since we don't have that luxury, a state of the art protection system that can be extended to all of our many points on the web is necessary. And sooner, not later.

Connect with Don:	Connect with F5:

Related Articles and Blogs