Do you want security “at your” or “as a” service?

The world of cloud computing had, until recently, settled down into its primary pillars of SaaS, PaaS, and IaaS. But as cloud consumers continue to mature in their understanding and use of cloud we’re starting to see an increased interest in what is part cloud, part managed service, particular in the area of security. For the sake of this blog, let’s call it “at your service”*. 

In a traditional “as a” environment, we might simply take BIG-IP ASM (our application firewall) and set up a nice F5 Synthesis services fabricsomewhere, out there, as a cloud and offer up it “as a Service”. From an architectural perspective it makes sense to put the application security closer to those apps that need it, in the cloud where there is still, today, a dearth of good alternatives. Apps hosted in the cloud are as (if not more) in need of application security than those in the data center, owing to their more public-by-design nature. What doesn’t necessarily make sense is forcing requests to the data center to be scanned and scrubbed and evaluated before sending them back out to the cloud. It’s a giant trombone (or hairpin, if you prefer) given that most data centers aren’t hanging right off the Internet backbone next to the cloud provider’s data center.

The growing preference for such a model was clear in our State of Application Delivery 2015 report, especially for security services.

But a cloud-based application security solution does make a lot of sense. It’s probably physically and topologically closer to the app it’s protecting than the corporate data center, and it offers a billing model more complementary to cloud-based apps than a traditional, on-premise solution.

The problem, however, is that you still have to have the time and knowledge to configure it and test it and, this is important, keep it up to date.

This is when “as a” really turns into “pain in the”. Because to accomplish this task you need the knowledge and the skills of someone who understands security and also understands the application. Which may be difficult in these security bubble times.

The differences between “as a” and “at your” are primarily around responsibility and involvement in management. In an “at your” service, you’re not just subscribing to the software or solution, you’re subscribing to the active management of that solution by folks who are experts in doing so. In the realm of security, given macro-environment pressures such as a skills shortage across IT that’s hitting information security particularly hard, the subscription to security expertise is certainly a boon, not to mention potentially economically savvy:

The IT skills shortage has become epidemic. There simply aren’t any security people available to hire. For five years now, the unemployment rate for InfoSec professionals has been less than 2% (and often 0%). The tight job market for people with security skills has had a predictable impact on wages: According to Payscale, in 2014, half of all security architects made more than $120K: that’s 50% more than the average software engineer—and a whopping 300% what a licensed nurse practitioner makes. People with security skills command more pay, leave for startups, or get poached for cushier jobs with better titles (ahem). ESG’s Jon Oltsik wrote that his #1 prediction for 2015 is “Widespread impact from the cybersecurity skills shortage.” – David Holmes, F5 Security Evangelist, Dark Reading

By combining the business and operational model of cloud (multi-tenancy, abstraction, subscription/utility based billing) with the traditional benefits of a managed service organizations gain the agility and cost savings desired. By providing the expertise both to configure and maintain the service while encouraging collaboration and active participation from the consumer, the “at your” model offers organizations the means to secure their critical applications** anywhere and be assured that security is covered. 

* Yes, I’m aware that abbreviates to SayS. No, I’m not sure that’s good. Or bad. Maybe both.

** In an application world this is pretty much every application, isn’t it? Almost seems redundant to modify it, now.