Security

A client is still a client even when it's on the space station

Lori MacVittie — Fri, 14 Nov 2008 11:08:28 GMT

While I was at SD Best Practices in Boston last month I got to talk to a lot of engineers, developers, and architects about their environments and about what F5 does for application delivery.

One of the developers glibly told me he wasn't sure we could help him out because his environment was the international space station.

Yeah, how cool is that? Now that's cloud computing.

Another architect, who turned out to be a friend of a friend who I've conversed with but never met in person said the same thing, but his environment was nuclear submarines.

The Internet, she is everywhere.

There are certainly challenges with developing and delivering applications for such unique environments, but in the end a client is a client and a network is a network, even if it's over satellite links - which is most certainly the case for locations that cannot be wired or take advantage of wireless technology. What's awesome about application delivery solutions is that they are primarily asymmetric, they are a proxy to the core network that is almost always physically located in a data center somewhere on, well, earth. And on dry land.

An application delivery platform mediates, and it is physically located at the edge of the physical network. If there's a client on the space station or a nuclear submarine or a cruise ship or airplane that can communicate via a network, then an application delivery solution can indeed help the performance, security, and availability of the applications being delivered to those very remote locations.

Asymmetric solutions, of which a reverse proxy is almost always one, do not require deployment of client-side software. They are one sided, hence the use of the term asymmetric. All you need is the application delivery solution to be deployed at the edge of the physical network and voila! You can begin taking advantage of acceleration features like caching, compression, and protocol optimizations. The application delivery platform is aware of the network across which applications must traverse to reach the client, but it doesn't require that it be a certain speed, or a certain type, or anything, really. As long as it's operating on standards-based network protocols like IP, you can take advantage of the features of an application delivery solution for your environment.

In fact, an application delivery solution is perfect for address many of the problems inherent in low speed, high latency links like those used to communicate with uber remote locations like the space station or a nuclear sub because it has the intelligence to understand the network conditions unique to each link and adapt in real-time to provide the best performance possible for users accessing data and applications over that link.

And because the application delivery platform mediates between clients and applications, it can provide availability services to clients regardless of their location. In fact, because most application delivery platforms are full-proxy solutions, they are particularly adept at managing each side of the equation individually, simultaneously improving data center efficiency, reliability, and performance while adjusting proactively to the conditions currently being experienced by the client.

Being contextually aware of the unique environment from which clients access applications over a network is part of the secret sauce of application delivery solutions. By being able to understand and adapt to conditions on a per-request basis it can optimize delivery of applications for everyone - whether they are at home, at the office, on the international space station, or 20,000 leagues under the sea.

Technorati Tags: MacVittie,F5,SD best practices,development,architecture,infrastructure,application delivery,context-aware,network,client,proxy,acceleration,security,internet,satellite,space station,submarine,adapt,performance,blog

Virtualization: How to Isolate Application Traffic

Lori MacVittie — Fri, 07 Nov 2008 14:33:15 GMT

Many people are concerned with virtualization security (already coined VirtSec), and they're applying that concern from the virtual images all the way down the stack, to the network infrastructure through which virtualized application traffic is delivered. The desire for network infrastructure to be itself virtualized is growing out of a perceived need to isolate application traffic at every point in the infrastructure. But the technology to isolate application traffic at layer 2 and 3 of the infrastructure already exists, and has been essentially virtualized for years.

The sudden desire for everything in the infrastructure to be virtualized completely is borne primarily out of security concerns. When you're running two or three or more virtual images on the same server it's natural to want them to be isolated from one another, so that a potential problem with one does not affect another. Too, it's an issue with keeping application data segmented, separated in order to clearly delineate the delivery path and to keep each stream of traffic pure.

Of course that's amusing as multiple applications deployed on the same application server container, such as IBM WebSphere or Oracle/BEA WebLogic, cross the streams necessarily, so the sudden "OMG we have to isolate traffic completely" is a bit incongruous with most architectures, but c'est la vie, right?

This leads to the belief that routers, switches, and application delivery solutions must be virtualized and compartmentalized such that application data is isolated even as its traversing the network.

But the actual mechanism for how this is accomplished does not need to mirror virtualization as it is understood at the operating system or application level because for many years we're have something called VLANs (Virtual LAN) that performs this task for us already.

VLANs are a standard layer 2 mechanism for segmenting and effectively isolating application traffic. Data on one VLAN cannot be seen or accessed by data traversing another VLAN, they are effectively separate streams. It is interesting to note that VLANs are one of the core technologies used to implement solutions such as NAC (Network Access Control) because it does the job and isolates "good" traffic from "might be bad" traffic in order to preserve the cleanliness of the network and protect access to resources. How the VLANs are used is part of the secret sauce of NAC and related technologies, with user traffic being moved from one VLAN to another as it moves through the authentication and authorization process. There's more to NAC than this, of course, but VLANs are almost always part of the equation - because they do the network side job so well without incurring the additional overhead of new infrastructure solutions.

That's because traffic assigned to different VLANs is isolated. Traffic on one VLAN cannot be seen or accessed by traffic on another VLAN. Servers on one VLAN cannot talk to servers on another VLAN unless a switch or router or other routing-capable device allows the traffic to pass across the VLANs.

VLANs are supported by all layer 2/3 capable devices today, which means just about everything - from routers to switches to load balancers to servers. The problem is that we've grown to use VLANs as an architectural tool rather than a security tool, and often don't consider how valuable such a simple, existing technology can easily be applied to more emerging, cutting edge concepts. In fact, VMWare has an excellent white paper on how to configure ESX 3 with VLANs using vSwitches that not only explains how to configure ESX to take advantage of VLANs, but also discusses VLANs in general including various approaches and their relative merits.

There's a lot of new technology you need to acquire and implement for a successful virtualization initiative, but products that specifically isolate application traffic using nifty new virtualized systems is not necessarily one of them. I'm sure there are architectures and business reasons why you might need more, but if you're just attempting to isolate application traffic as due diligence, you may be overanalyzing the situation. Your existing infrastructure is almost certainly VLAN capable right now, and can likely be used right now to accomplish your goals of isolating application traffic.

Sometimes the answer to a problem really is an existing technology or solution, you've just got to cut through the hype out there to find it.

Technorati Tags: MacVittie,F5,network,VLAN,virtualization,application,traffic management,switch,router,internet,web,application delivery,security,NAC,VMWare,ESX,blog

3 steps to a fast, secure, and reliable application infrastructure

Lori MacVittie — Thu, 23 Oct 2008 11:40:38 GMT

You have just been promoted to CTO of Widgets, Inc. (Congratulations, by the way!) In your new role, on which of the following will you focus the most attention (and budget):

(a) the network

(b) the applications

Trick question. The answer is (d) all of the above. I know I didn't list that choice (I did in the poll, however) but you've taken multiple choice quizzes before; there's always a choice (d) all of the above. Always. And 25% of the time it's the right answer. In the case of technology today, it's always the right answer.

As an industry we spend a lot of time (and money) worrying about how to protect our applications and the data that drives them. We spend a lot of time (and money) agonizing over how to scale and keep available those applications which are crucial not only to our business users but our customers and partners. We spend a lot of time (and money) trying to make those applications faster and better and easier to use.

The network, however, is often left out of the discussion (and the budget). Like the local road, most people don't think much about it until there's a pothole that slows you down or causes a flat tire. Then it gets a lot of attention - and most of it negative.

This lack of attention to the network and its importance to scale and reliability and security is problematic and pervasive. So pervasive that research firm Gartner recently penned a research note on the subject of the network and cloud computing entitled, "You Can't Do Cloud Computing Without the Right Cloud (Network)." [reprint courtesy of F5]

There are four different types of networks supporting "cloud computing" and each react differently to different application characteristics. These differences are critical to the selection of a cloud network vendor.

Four different types of networks supporting cloud computing. I'm guessing that holds true for non-cloud computing architectures as well. There are many different types of networks and architectures and this is, in part, why the network is always, always depicted as nothing more than an amorphous cloud in application architecture diagrams.

Many of Gartner's key findings mirror what we've been asserting are four key attributes of infrastructure supporting cloud computing, whether that cloud is a big one "in the sky" (Internet) or a smaller one "in the backyard" (in your data center). In general, it mirrors what we've been saying for years with regard to improving application performance and scalability: the network is more important than most people tend to believe. It's not just a "pipe", it's an integral part of your architecture and is inherently important to the successful deployment and delivery of applications.

Data is the lifeblood of an organization, and applications are the heart of the data center. On that there is no argument. But the network is the complex system of veins and arteries that carries that lifeblood to and from the heart (applications) and without them, well, your business is likely faltering if not dead.

Just as doctors try to impart upon us the importance of preventive medicine and a healthy diet, it's just as important to apply that practice to IT in general. We need to be proactive and take preventive action whenever possible in order to deliver applications that are fast, secure, and available. And that means keeping the network on the same level of importance as the data and applications it is serving. That means investing in technologies that make the network better, faster, and more able to continue transporting data between the applications and the users that need them.

The network can inhibit the delivery of applications or it can enhance the delivery of applications. Which is ultimately up to you, and based upon what role you assign it within your application infrastructure.

The first step is recognizing that the network is as important as the applications and data it is delivering.

The second step is discovering how the network might help in deploying and delivering those applications and providing value above and beyond its traditional role of "just a pipe."

The third step is to do something about it.

Technorati Tags: MacVittie,F5,Gartner,cloud computing infrastructure,cloud computing,architecture,infrastructure 2.0,data,applications,network,application delivery,fast,secure,availability,scalability,web,internet

How to prevent content theft using Apache mod_rewrite or F5 iRules

Lori MacVittie — Tue, 21 Oct 2008 10:31:51 GMT

Over the years imaginative developers have come up with a number of ways through which they hope to stop the pilfering of their images. Whether due to copyright issues or the increased bandwidth and associated costs resulting from "hot linking", site owners have tried a variety of solutions from JavaScript that prevents the ability to right-click and "save as" to watermarking high-resolution versions to make their images less appealing to image thieves.

Regardless of the reason you may want to prevent image theft, there's an easier and more effective method than introducing easily countered JavaScript and costly alternative technology solutions.

HTTP REFERER

Every web request made via HTTP comes with a set of standard HTTP headers. One of those headers is the referer (interesting spelled incorrectly), which indicates the domain and URL from which the request was made. If the request was direct (e.g. typed into the address bar by the user or loaded from a bookmark) then the referer header will be empty and usually displays in logs as "-" (at least they do on Apache). Otherwise, the referer header will have the FQDN (Fully Qualified Domain Name) of the referring page.

The referer header is central to this solution; by checking the referer header you can determine whether the request for your image came from a page on your site or someone else's or was a direct request. If you're trying to prevent theft obviously you only want to allow access to images if the request came from a page hosted on your site. So the referrer must contain your unique domain name (or any domain name you wish to allow access to) or the request should be denied.

Once you've determined that the referrer is not allowed access to the image, you'll want to rewrite the URL (there are caveats with this, so be careful) or respond in such a way as to indicate to the client that the image is not available for viewing.

IMPLEMENTING THE SOLUTION

In order to implement the solution you'll need to be able to intercept the request and examine the headers to determine its validity. We'll look at both mod_rewrite (Apache) and F5 iRules (BIG-IP) as a mechanism to do this.

mod_rewrite

iRules

(mod_rewrite code courtesy of: Debian Administration)

Rewriteengine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://example.com/.*$ [NC]
RewriteRule .*.(gif|GIF|jpg|JPG)$ - [F]

when HTTP_REQUEST {          
   set thief 0        
   set uri [HTTP::uri]          if {[matchclass $uri ends_with $::images] > 0 } {          
      if {[HTTP::header value Referer] contains "example.com"} {
         set thief 0          
      }          
      else {          
         set thief 1          
      }          
   }          
   if {$thief eq 1} {          
      HTTP::respond 200 content ""          
   }          
   else {          
      pool mywebsite_pool           
   }          
}

That's pretty much it. You could get creative and respond with an actual image, or rewrite the URI to be a different image. If you choose the latter, be aware that you'll need to add code to handle that exception case, or you'll put the client into a redirection loop. After all, the referrer is still not your site, so redirecting to another image will fall into the same code unless you specifically catch it. While Firefox will recognize this infinite loop and stop requesting the image, IE 7 just keeps trying, which is somewhat amusing but floods the network with requests that aren't going to get answered and uses up a connection on your web server or BIG-IP.

This solution obviously can be used to stop hotlinking to any type of content: Flash, video, audio, text. You only need change the extensions you are looking for to match those used by the content in question. You could also get more sophisticated and set up a system whereby allowed domains are given a cookie, which you can subsequently check to determine whether access should be allowed. You could also use this logic to stop specific domains from hotlinking to your content by checking the referer header against a list of allowed sites and refusing to serve the content to sites not on the list.

The nature of an intelligent mediator is such that you can pretty much come up with just about any solution involving HTTP headers and implement it fairly easily. There are advantages to using a full-proxy solution over mod_rewrite, but both will definitely provide a platform on which you can deploy a solution that can prevent content theft.

Technorati Tags: MacVittie,F5,iRules,BIG-IP,mod_rewrite,Apache,Flash,images,theft,rewrite,hotlinking,firefox,IE7,referer header,HTTP,internet,web

Is OpenID too open?

Lori MacVittie — Mon, 20 Oct 2008 11:02:43 GMT

One password to fool them all

One password to find them

One password to steal them all and in the ether become them

[with many apologies to J.R.R. Tolkien]

For years we've had it beat into our heads that using the same username and password for everything on the web leaves us open to compromise and identity theft. The on-demand nature of conversations and social networking has apparently left us all bereft of our wits as we embrace the very concept we've been warned about for years. But is it really as dangerous as we've been led to believe?

The concept of a single identity that can be shared across disparate sites is hardly new. Liberty Alliance proposed SAML as the underlying technology to provide a single sign on (SSO) functionality for the web years ago and it competed with Microsoft's Passport for mindshare.

But neither took off; both were "ahead of the times". Social networking hadn't taken over the web yet, and people didn't really see a need to take the risk.

That was then, this is now.

OpenID is succeeding where the Liberty Alliance with SAML and Microsoft's Passport (now "Live ID") failed. It's easy to use, easy to integrate with your own site, and seems to be everywhere. Just set up a single identity at OpenID or a participating site like Technorati and you can use that same identity over and over to sign into hundreds of social networking sites around the web.

Despite knowing that it's dangerous (or so we're told), that it's a risk (and a big one at that, they say), hundreds of thousands of us (and that 'us' is mutually inclusive, mind you) use OpenID either directly or indirectly by tying our identities at myriad social networking sites to a single identity. We do this despite knowing that if that single identity is compromised that it can be used against us at every site through which we use that identity to interact with others.

The uber-security minded folks may now commence screaming and holding their head in pain as they morph into something out of an Edvard Munch painting at what I'm going to say next.

HOW MANY WALLETS DO YOU CARRY?

The risk appears to be minimal, despite the advertisements and scary articles to the contrary, and the benefits apparently outweigh that risk. Much in the same way we rail against additional security precautions at the airport, referring to them as unnecessary and doing nothing but offering a false sense of security, perhaps the "never use the same password" precaution, too, offers little more than a false sense of security.

As Alan Shimel unfortunately discovered recently, separate identities doesn't really add a lot of security when the identity information is aggregated in a single place, which it all too often is. Compromise of your primary e-mail account is also likely to end up with your online identity compromised, whether you used OpenID or not.

The risks for you and I (I assume you aren't Alan Shimel, Robert Scoble, or Paris Hilton) having our identities targeted and stolen are likely on the same level as having our wallet stolen. If we leave it out on the table and walk away, yeah, it's probably going to get stolen. The digital equivalent would be, oh, posting the information somewhere public or using that single identity on a site that seems a bit less than trustworthy - or isn't implementing best practices in securing that data and preventing theft.

If you don't carry more than one wallet to protect your multiple credit cards and your identity, then is it really a problem using only one "digital wallet" to store you identity online? Probably not, as long as the owners of the sites at which you can use your OpenID are taking steps to ensure the security of the site and the underlying data.

MITIGATION OF THE RISK IS ON THE SITE, NOT THE USER

The risk of theft really has very little to do with users today, as we don't typically share our identities and passwords publicly. The risk has to do with the sites we frequent and what kind of security they have in place to prevent exploitation of vulnerabilities and data theft. There are no real regulations in place regarding notification of data loss for sites not storing personally identifiable information, as there are for financial and healthcare related institutions, so we may never know. And it's unlikely that your bank is going to offer OpenID as a means of identifying yourself. I shudder to even consider that as an option.

All things considered, using OpenID or at least the manual implementation of OpenID (same username/password over and over) doesn't seem to be really all that much of a risk unless you also use it for your online financial and healthcare information.

And I know none of us are doing that, are we?

Technorati Tags: MacVittie,F5,application security,OpenID,Liberty Alliance,SAML,Microsoft,Live ID,Passport,SSO,integration,password,e-mail,compromised,identity theft,security,Alan Shimel,Robert Scoble

Cloud Computing and Infrastructure 2.0

Lori MacVittie — Fri, 17 Oct 2008 10:58:35 GMT

Not every infrastructure vendor needs new capabilities to support cloud computing and infrastructure 2.0.

Greg Ness of Infoblox has an excellent article on "The Next Tech Boom: Infrastructure 2.0" that is showing up everywhere. That's because it raises some interesting questions and points out some real problems that will be need to be addressed as we move further into cloud computing and virtualized environments. What is really interesting, however, is the fact that some infrastructure vendors are already there and have been for quite some time.

One thing Greg mentions that's not quite accurate (at least in the case of F5) is regarding the ability of "appliances" to "look inside servers (for other servers) or dynamically keep up with fluid meshes of hypervisors".

From Greg's article:

The appliances that have been deployed across the last thirty years simply were not architected to look inside servers (for other servers) or dynamically keep up with fluid meshes of hypervisors powering servers on and off on demand and moving them around with mouse clicks.

Enterprises already incurring dis-economies of scale today will face sheer terror when trying to manage and secure the dynamic environments of tomorrow. Rising management costs will further compromise the economics of static network infrastructure.

I must disagree. Not on the sheer terror statement, that's almost certainly true, but on the capabilities of infrastructure devices to handle a virtualized environment. Some appliances and network devices have long been able to look inside servers and dynamically keep up with the rapid changes occurring in a hypervisor-driven application infrastructure. We call one of those capabilities "intelligent health monitoring", for example, and others certainly have their own special name for a similar capability.

On the dynamic front, when you combine an intelligent application delivery controller with the ability to be orchestrated from within applications or within the OS, you get the ability to dynamically modify configuration of application delivery in real-time based on current conditions within the data center. And if you're monitoring is intelligent enough, you can sense within seconds when an application - whether virtualized or not - has disappeared or conversely, when it's come back on line. F5 has been supporting this kind of dynamic, flexible application infrastructure for years. It's not really new except that its importance has suddenly skyrocketed due to exactly the scenario Greg points out using virtualization.

WHAT ABOUT THE VIRTSEC PIECE?

There has never been a better case for centralized web application security through a web application firewall and an application delivery controller. The application delivery controller - which necessarily sits between clients and those servers - provides security at layers 2 through 7. The full stack. There's nothing really that special about a virtualized environment as far as the architecture goes for delivering applications running on those virtual servers; the protocols are still the same, and the same vulnerabilities that have plagued non-virtualized applications will also plague virtualized ones. That means that existing solutions can address those vulnerabilities in either environment, or a mix.

Add in a web application firewall to centralize application security and it really doesn't matter whether applications are going up and down like the stock market over the past week. By deploying the security at the edge, rather than within each application, you can let the application delivery controller manage the availability state of the application and concentrate on cleaning up and scanning requests for malicious content.

Centralizing security for those applications - again, whether they are deployed on a "real" or "virtual" server - has a wealth of benefits including improving performance and reducing the very complexity Greg points out that makes information security folks reach for a valium.

BUT THEY'RE DYNAMIC!

Yes, yes they are. The assumption is that given the opportunity to move virtual images around that organizations will do so - and do so on a frequent basis. I think that assumption is likely a poor one for the enterprise and probably not nearly as willy nilly for cloud computing providers, either. Certainly there will some movement, some changes, but it's not likely to be every few minutes, as is often implied.

Even if it was, some infrastructure is already prepared to deal with that dynamism. Dynamism is just another term for agility and makes the case well for loose-coupling of security and delivery with the applications living in the infrastructure. If we just apply the lessons we've learned from SOA to virtualization and cloud computing and 90% of the "Big Hairy Questions" can be answered by existing technology. We just may have to change our architectures a bit to adapt to these new computing models.

Network infrastructure, specifically application delivery, has had to deal with applications coming online and going offline since their inception. It's the nature of applications to have outages, and application delivery infrastructure, at least, already deals with those situations. It's merely the frequency of those "outages" that is increasing, not the general concept.

But what if they change IP addresses? That would indeed make things more complex. This requires even more intelligence but again, we've got that covered. While the functionality necessary to handle this kind of a scenario is not "out of the box" (yet) it is certainly not that difficult to implement if the infrastructure vendor provides the right kind of integration capability. Which most do already.

Greg isn't wrong in his assertions. There are plenty of pieces of network infrastructure that need to take a look at these new environments and adjust how they deal with the dynamic nature of virtualization and cloud computing in general. But it's not all infrastructure that needs to "get up to speed". Some infrastructure has been ready for this scenario for years and it's just now that the application infrastructure and deployment models (SOA, cloud computing, virtualization) has actually caught up and made those features even more important to a successful application deployment.

Application delivery in general has stayed ahead of the curve and is already well-suited to cloud computing and virtualized environments. So I guess some devices are already "Infrastructure 2.0" ready.

I guess what we really need is a sticker to slap on the product that says so.

Technorati Tags: MacVittie,f5,virtualization,hyper-v,microsoft,vmware,virtsec,security,application security,application deilvery,infrastructure,application delivery controllers,load balancers,dynamism,cloud computing infrastructure,cloud computing

Is Twitter the newest data security threat?

Lori MacVittie — Thu, 16 Oct 2008 11:00:02 GMT

One of the most dangerous threats to data security is also one of the least talked about: employees. Are Twitter and other microblogging sites yet another avenue through which sensitive data can leak out of the corporate database and into the hands of ... anyone? Perhaps more worrisome, what information are you giving away simply by being a part of the community?

Of course Twitter is a potential threat. Like personal e-mail accounts and instant messaging, Twitter and sites of its ilk are primarily messaging mechanisms, which translates into personal channels for exporting sensitive data outside the enterprise. If you aren't familiar with Twitter, its messaging mechanisms allow several "modes" of communication: a blast to the general twitterverse, a public reply to a specific twitter user, and a direct (private) message to another twitter user. The direct messages aren't displayed in your public timeline, only the intended recipient can see them, so they're perfect for sneaking out tidbits like customer information or competitive information like upcoming product features/launches.

Despite the good intentions of compliance initiatives like HIPAA and PCI DSS, implementation of security measures designed to comply with these standards tend to focus mainly on the easiest and most obvious ways in which sensitive personal information can be lost, stolen, or shared: web applications.

But Twitter is a web application, you say, so shouldn't it be covered?

Perhaps, but it likely isn't. Current regulations tend to concentrate on preventing data from being taken out of the enterprise database, not cut-and-pasted into a tweet or e-mail or instant message. While monitoring and even filtering of web applications is commonplace today, it's almost universally focused on filtering of inbound web content, not outbound except at the URI or domain level. Content filtering solutions can stop inbound web content containing naughty words and those naked pictures of Bea Arthur the transfer of which no one can explain. But they don't generally focus on filtering outbound requests and POST data, despite the inherent risk in allowing unfettered communication with the outside world.

There have been solutions offered to prevent this exact scenario from happening via e-mail, but monitoring around web and even instant messaging continues to primarily focus on inbound content rather than outbound content. This makes microblogging sites like Twitter a potential security risk when attempting to secure all the possible avenues through which sensitive corporate data may be leaked.

What's necessary to block these holes is a two-pronged attack posture:

Reiterate to employees the ramifications of exporting sensitive data, including recognition of having read and agreed to organizational policies regarding how the organization will deal with proven breaches involving data security. Hint: A slap on the hand may not be harsh enough, though getting medieval on them may be too much. Maybe.
Consider the implementation of a forward proxy security solution capable of at the very least monitoring outbound web content (over HTTP) and optimally blocking anything that appears to be a credit card or social security number or anything else that might be considered sensitive personal information.

Proactive information security (sometimes also known as 'due diligence' in legal speak) requires recognizing both possible holes and acting to block them.

CAN YOU SHARE TOO MUCH INFORMATION?

And even if you aren't concerned about Twitter as a possible data security threat, you might consider the number of brands that are using Twitter to communicate with customers. That means the folks following a particular brand (company) could be viewed as a very public customer list. In the past, vendors - especially startups, for whom Twitter is particularly attractive - have aggressively guarded their customer lists so that competitors can't swoop in and convince them to "change sides". Twitter offers a public view of customers - and potential customers - that could be easily used in sales strategies to obtain new customers.

Conversely, some companies have always been reluctant to admit whose solutions they use for security and software because they are juicy targets for bad guys. Letting the bad guys know which solutions might be securing or serving up their corporate data gives them an edge, and if employees are following a "brand" it might be a hat tip to those intent on harm or theft as to how to target their attacks.

Whether it's direct leaks of information coming from employees or inadvertently allowing too much information about customers or your own infrastructure to leak out publicly through deductive reasoning based on who you're following, the use of Twitter should be viewed as both a possible business benefit and a potential security threat.

Twitter and sites of its ilk are definitely a possible hole in your security strategy (isn't everything in the eyes of information security folks?) and should be evaluated and if necessary addressed sooner rather than later.

Related Links

The Unpossible Task of Eliminating Risk

What IT Security can learn from a restroom sign

PCI DSS Requirements 6.6: A best practice for the rest of us

New TCP vulnerability about trust, not technology

Technorati Tags: MacVittie,F5,application security,web security,security,Twitter,microblogging,risk mitigation,compliance,monitoring,filtering,http,web,internet,HIPAA,PCI DSS

Data center consolidation drives business case for secure remote access

Lori MacVittie — Mon, 13 Oct 2008 11:16:09 GMT

Everybody is jumping on the data center consolidation bandwagon again. It never really went away, it just took a leisurely Sunday drive through the countryside for a few years before turning back up on the streets of busy data centers everywhere.

RELATED LINKS

This time, it's virtualization that's driving consolidation, and this time it appears that the movement may actually have a better chance at success.

Virtual Server Sprawl: FUD or FACT?

Server Virtualization versus Server Virtualization

Telecommute your way to a greener bottom line

The original intent of data center consolidation was to remove the expense of managing remote servers at physically disjunct offices. Often there was very little technical support available at these remote locations, making troubleshooting - even with remote desktop access to the servers - a difficult and painful task. Resolving outages and other issues often requires a physical presence, which meant increased travel costs.

The problem with consolidation is that remote employees still need to access core applications, like CRM (Customer Relationship Management) and ERP (Enterprise Resource Planning) and call center applications.

These applications often access data that is considered by multiple industry regulations to be personally identifiable and sensitive in nature, requiring that the data be secured in transit.

Securing data in transit can be accomplished, through web applications at least, by enforcing the use of SSL for all such applications. But it often the case that doing so can inhibit performance of those applications at corporate headquarters as well as for those accessing the application remotely, which can decrease productivity. Decreases in productivity ultimately cost the organization real dollars, which would certainly offset the benefits and savings seen by consolidation efforts in the first place.

A better option is to provide secure remote access to corporate resources via an SSL VPN to those remote offices. An SSL VPN can offer as much or as little access to corporate resources (file shares, applications, etc...) as desired by the organization without sacrificing performance. That's because a well-designed SSL VPN includes SSL accelerated hardware to assist in the encryption and decryption of data, which means less of a degradation of performance for remote employees and no degradation for employees accessing those same applications via the LAN.

An SSL VPN can further extend the ability of traveling or roaming employees to access critical business applications when necessary, as they are not as restrictive as IPSEC VPNs. Because SSL VPN technology utilizes an on-demand client model, there's no need to manage or troubleshoot remote endpoint clients. The endpoint clients are downloaded on-demand, which supports a dynamic environment that can expand or contract with organizational policy immediately. No need for lengthy rollouts or scheduled installations.

Consolidation is driven by the need to reduce operating costs across a wide variety of areas including power consumption, heating, cooling, and maintenance. An SSL VPN can extend that model out to remote offices while simultaneously providing the security necessary - and in many cases legislated - to offer remote access to core organizational applications.

Technorati Tags: MacVittie,f5,ssl vpn,secure remote access,consolidation,virtualization,application delivery,crm,erp,ssl,security,regulations,internet,applications

Google claims analyst research firm site is an attack site, serving up malware

Lori MacVittie — Fri, 10 Oct 2008 13:00:49 GMT

I was reading an interesting article on the return on investment for WAN Optimization solutions as discussed by analyst research firm Aberdeen and decided to download the complimentary copy of the report. Reports are generally offered as PDF downloads, not displayed in Macromedia FlashPaper, so it was not easily obtainable for sharing with friends. However, there's a nice "e-mail to a friend" link so I clicked on it, thinking of many folks I know who might be interested in this report.

The next thing I know my screen is screaming at me with a warning about malicious content and that the site had been blocked per my security settings. Note: the security settings in my browser (Firefox) are the default; I haven't changed them. I like to live dangerously like that.

Needless to say this got my attention immediately. What could possibly be going on that would result in this site being designated as an "attack site" and therefore dangerous? After all, BusinessWeek was infected not so long ago, so it's not inconceivable that Aberdeen could be infected as well.

So I opted to use the "Why was this site blocked? " button and see what Google had to say about the site.

It wasn't pretty. No, not the diagnostic page, the information contained therein.

According to the Google diagnostic page, "Of the 40 pages we tested on the site over the past 90 days, 10 page(s) resulted in malicious software being downloaded and installed without user consent. The last time Google visited this site was on 09/30/2008, and the last time suspicious content was found on this site was on 09/30/2008."

Several thoughts came to mind after reading the diagnostic page.

Whoa. Really? That's scary stuff!
That was two weeks ago. Shouldn't Google be more proactive in checking more regularly once it identifies an "attack site" to see if the situation has been remedied?
Does Aberdeen know this? Did Google send them a nice note saying "Hey, your site is doing bad things. You should fix it." or is this process so completely automated as to ignore the fact that sometimes sites are infected by third-party content and isn't detected by the site owner until it's pointed out.
Is this perhaps a problem with Adobe's Macromedia FlashPaper? A misidentification of intended functionality as malicious? Google's diagnostic page seems to indicate something more devious, but stranger things have happened, especially on the web.
If the site is infected, and it was infected via some sort of injection (SQL, XSS, etc...) could it have been prevented by a web application firewall? Hey, the word marketing is in my title, after all, so don't look at me like that. I have to wonder about these kinds of things. Because hey, it could be a new vulnerability that involves FlashPaper or Adobe products in general, like the recently discovered clickjacking vulnerability.

If this really is a problem and Aberdeen's site really is infected with malicious "stuff", then I'm thankful Google stopped me from viewing the site. But if it isn't a problem and Google's determination is incorrectly labeling intended functionality as malicious, then it's not so cool after all.

It will be nice to find out what's really going on. Is Aberdeen's site really infected? Is there yet another vulnerability with Adobe's products? Is the Google safe browsing function really working? Does Joanie still love Chachi?

So many questions, so few answers.

Technorati Tags: MacVittie,F5,WAF,web application firewall,Google,Aberdeen,mailicous,infection,malware,security,web security,internet,web,analyst

8 things you can do with a proxy

Lori MacVittie — Wed, 08 Oct 2008 11:27:35 GMT

After having recently discussed all the different kinds of proxies that exist, it occurred to me that it might be nice to provide some examples of what you can do with proxies besides the obvious web filtering scenario. This is by no means an exhaustive list, but is provided to show some of the more common (and cool, I think) uses of proxies.

What's really awesome is that while some of these uses are available with only one type of proxy (reverse or forward), a full proxy can provide all these uses, and more, in a single, unified application delivery platform.

1. DATA SCRUBBING

Data scrubbing is the process of removing sensitive information like credit card and social security numbers from web application responses. This is particularly useful in preventing data leaks, especially if you're subject to regulations like SOX, HIPPA, and PCI DSS where the penalties for divulging personally identifiable information can be harsh fines - or worse.

Data scrubbing is is an implementation of a reverse proxy.

2. URL REWRITING

Rewriting URLs is something everyone has likely had to do at one time or another if they've developed a web application. URL rewriting is used to refer web requests to new resources instead of sending out a redirect response in cases where resources have moved, renamed, or migrated to a new version.

URL rewriting is an implementation of a reverse proxy.

3. LAYER 7 SWITCHING

Layer 7 switching provides an organization with the ability to maximize their IP address space as well as architect a more efficient, better performing application architecture. Layer 7 switching routes specific web requests to different servers based on information in the application layer, like HTTP headers or application data.

Layer 7 switching is an implementation of a reverse proxy.

4. CONTENT FILTERING

The most common use of proxies is content filtering. Generally, content filtering allows or rejects requests for content based on organizational policies regarding content type, the existence of specific keywords, or based on the site itself.

Content filtering is an implementation of a forward proxy.

5. REDIRECTION

Redirection is the process of, well, redirecting a browser to a new resource. This could be a new instance of a requested resource or as part of application logic such as redirecting a failed login to the proper page.

Redirection is generally implemented by a reverse proxy, but can also be implemented by a forward proxy as a means of redirecting rejected requests to an explanation page.

6. LOAD BALANCING

Load balancing is one of the most common uses of a reverse proxy. Load balancing distributes requests for resources across a number of servers in order to provide scalability and availability services.

Load balancing is an implementation of a reverse proxy.

7. APPLICATION FIREWALL

An application firewall provides a number of functions including some in this list (data scrubbing and redirection). An application firewall sits in front of web applications and inspects requests for malicious content and attempts to circumvent security.

An application firewall is an implementation of a reverse proxy.

8. PROTOCOL SECURITY

Protocol security is the ability of a proxy to enforce protocol specifications on requests and responses in order to provide additional security at all layers of the OSI stack. Protocol security provides an additional layer of security atop traditional security mechanisms that focus on data.

Protocol security is an implementation of a reverse proxy.

Technorati Tags: MacVittie,F5,BIG-IP,proxy,reverse proxy,forward proxy,full proxy,security,load balancing,application delivery,protcol security,URL rewriting,content filtering,data scrubbing,application firewall,internet,web