I’ve heard the buzzwords but wasn’t exactly sure what they meant–luckily, when there’s media hype, there are definitions, too. According to this article, cloud computing is exemplified by Software as a Service — outsourced, hosted platforms and software that perform services for companies.

Another article puts it slightly differently:

OK, let us look at what form of computing in being provided via the cloud. In this model, all IT applications and facilities (i.e. compute, storage and network) are provided as a service rather than dedicated infrastructure. This is intended to allow any user, independent of client platform, to access IT services without knowledge or concern of their location or form. Sound familiar — it’s a service-oriented architecture (SOA)!

In addition, cloud computing incorporates almost every computing manifestation within the IT world: distributed, grid, utility, on-demand, open-source, Web services, P2P, Web 2.0 and, last but not least, software as a service.

It also accommodates thin, thick and mobile clients and allows integration of corporate, commercial and service provider cloud-accessed resources. As an example, in this model, storage is a service resource that is accessed via the cloud, not a dedicated user resource.

Honestly I read that last one first and found the definition a bit dense. It sounds like a summation of everything that makes up our Internet infrastructure already, so how is that different than the Internet itself? Well, cloud computing isn’t about what service or devices are being supported — it’s more about how it’s being provided– it is a location-independent style of computing. The first article calls it “platform as a service.”

Have you heard better definitions of what cloud computing is and does? Share them in the comments below. Thanks!

O2 will offer iPhone 3G for free along with extensive Wi-Fi coverage: AT&T may still be sorting out how Wi-Fi service will be included in its cell plans, but O2 had already provided free Wi-Fi to supplement scanty EDGE service in the UK. The new iPhone 3G will be offered fully subsidized to subscribers of £45 or higher tariffed services, along with 9,500 hotspots through BT OpenZone and The Cloud.

SanDisk buys MusicGremlin: The innovative Wi-Fi-enabled music player was and remains far in advance of the features found in the iPod touch, iPhone, and Zune, but the company behind the product couldn't get a fire lit under it. Sales figures were never disclosed, but it's never been on the list of top-selling players in the market. SanDisk's acquisition will shut down the product and its music service, but it will absorb the people and technology. I met with the founders of the company many years ago, and were impressed by how far ahead they were of everyone in the industry.

Zyxel introduces VOIP-connected Wi-Fi camera: I think they threw a bunch of buzzwords into a blender, but it's rather clever. The camera connects to a network via Wi-Fi, and has SIP (Session Initiation Protocol) embedded. SIP is used for VoIP and as part of gatewaying Internet telephony. The V750W gets its own phone number, and can be controlled remotely through either a real phone using the public telephone network, or a soft phone using SIP. It's being resold, not sold to consumers directly, as a monitoring tool. It includes two-way audio. The camera can also place a phone call if an intruder monitor is tripped. Why not just give it an IP address like other such cameras? SIP, if implemented correctly, can traverse private networks' NAT (Network Address Translation) gateway limits.

Why? Well, the problem with layered security is that we tend to assume if Layer X isn’t providing a particular protection, Layer Y must be… and we all know what assuming does.

In the good ol’ days, we relied on firewalls- perhaps nested firewalls, or ones positioned strategically on the LAN as well as the WAN. Because of our network architecture at the time, that was the primary (and probably only required) protection. After years of de-perimeterization and the increase of threats from both remote-access and insiders, we have a much different landscape.

The addition of resources and availability in the network has lead to the addition of vulnerabilities and threats.

Now… our schools need to protect children from material online. Now… we need to stop Trojans from sneaking in with VoIP apps. We need to access our corporate network securely from Starbucks. Our corporations need to protect their network from users accessing or publishing illegal content on the Internet. We need to protect our email, make sure its virus-free and not allowing employees to send sensitive information to the outside world.

All these increased risks and threats lend to the need for more protection in the environment. There’s just no single silver bullet or cure-all for the problems we’re facing.

What does this mean? It means we’re adding security products to the network to address these issues. We need content filtering. We need layer-7 visibility on the WAN for inbound/outbound application control. We need data leakage prevention. We need email security. We SSL-VPNs for secure remote access… the list goes on.

So, what’s the problem? We’re living in a world of security buzzwords and ‘hot topic’ solutions. But the problem is 2-fold.

Problem 1- We forget to KISS IT. In the frenzy to understand and implement these hot new products, we’re losing sight of some basic security functions and overlooking some really important security fundamentals. Remember to KISS IT and keep your basic security solutions simple- then layer on top of that. Your hot new NAC or DLP solution won’t seem so impressive if your basic firewall rules haven’t been properly configured.

Problem 2- We forget thy layers. After you KISS IT, you need to start layering responsibly. That means having a CLEAR understanding of what each solution does- or does not- do. You wouldn’t believe how many customers call and want to hear about Widget A for a certain solution that Widget A is not designed to fix. I deal with it daily and I blame (for the most part) vendors for mis-advertising their product as a fix-all. Whether its hardware or software- know what each piece of your security solution is designed to do, what it’s actually doing, and keep that information documented. Documented- I’m going to say it again. Your firewall/UTM may offer content filtering and gateway AV, but are you using it? Are you using a WAN optimization product to stop prohibited applications, or is your web filter doing that? Do you even know?

Solving the Cube. Layered security is like solving a Rubik’s Cube. You may think you’re on the right track after you get one side solved… but the other 5 are just a huge mess. There are patterns and algorithms you must follow to solve all sides together. Your layered security solution is no different. Understand what each piece is doing, how it fits in, and when to twist one layer here to implement a solution as part of a different layer over there.

# # #

You’ve read the headlines.  You’ve heard the buzzwords.  

Cloud Computing just seems like hype, right?  

“But it’s just another technology getting hyped to the max”.

The best case scenario is that your analysis is correct and you can go back to reading Slashdot and Daily Dave (you are reading Daily Dave aren’t you?).  You can pride yourself on your ability to recognise web hysteria and laugh at the losers that invested, wrote blog posts (!) and dared to take it seriously.

OK.  Now lets flip that around and just say for a moment you’re wrong - that Cloud Computing turns out to be a huge deal and takes off.  What could that mean for your day job?  No in-house servers to secure?  No in-house security operations to deal with? No in-house penetration tests to run?  No vulnerability assessment tools to run? No incident response where you actually ‘do something’?  

One scenario is you find yourself on a constant round of conference calls with 3rd parties trying to ‘pin down’ security in the cloud…  If you thought handling security issues associated with outsourcing was painful and slow, the Cloud will bring a multitude of competing providers that decision makers can switch from ‘digitally’ when the numbers ($$) make sense.

As the person responsible for your employer’s security arrangements, you may want to consider these 5 reasons for not dismissing Cloud Computing out of hand:

• Unless you work for an IT company, your employer did not go into business to ‘do IT’.  They are in business to sell a product or a service - in-house IT may have enabled that up to now but it was out of need rather than desire.  Cloud Computing has hit the cover of popular business magazines - its starting to get on the radar of CEO’s that ask questions like ‘how can I cut my costs?’, ‘how can I make my business more agile?’.  They may not switch overnight, but once the first goes in a given vertical, the clock is ticking.
• The temptation to contractually outsource security responsibility.  ”Our customer data got stolen from a cloud storage provider - not us - we don’t run IT!”.  Sure the buck stops with the org from a regulatory perspective but media coverage around recent data leakages involving 3rd party providers illicits a mixed reaction and thus diffuses the “reputation issues” to some extent.
• The skills you need to deal with Cloud Security may be different from the skills you have today.  Your “window” on Cloud security will be what the Cloud Provider gives you.  Beyond that you may be able to do an on-site audit from time to time but its a shared facility so no monkey in a cage pen-testing, scanning or filesystem forensic analysis.
• There’s a large cloud forming over the horizon.  The level of investment by providers doesn’t bear ignoring.  IBM, Google, Amazon, Microsoft and others are ploughing hundreds of millions of dollars building out data centers specifically for Cloud Computing.
• You may just end up working for the Cloud Provider!  This is something I believe will start happening in the next 2-3 years.  If you need a second opinion, go see Richard Bejtlich’s blog when he shared his own perspective.

What say you?  Hype or pending reality?

Welcome to the launch of the Cloud Security blog!

This blog is dedicated to “Cloud Computing” from an IT security perspective.

Cloud Computing is a nebulous term covering an array of technologies and services including; Grid Computing, Utility Computing, Software as a Service (SaaS), Storage in the Cloud and Virtualization.  There is no shortage of buzzwords and definitions differ depending on who you talk to.

The common theme is that computing takes place ‘in the cloud’ - outside of your organisations network.

Semantics aside, there is a much bigger question: what does it all mean from an IT security perspective?   How should we as an IT security community be thinking about these technologies?  What are the risks and how should we assess them?  And when things go wrong - when threats become realised - how should we respond?

If you are curious about “securing the cloud” or you are grappling with these questions, then stay tuned.

Enjoy,

Craig Balding

While all the innovative start-ups were working steadily on a new generation of security solutions, a majority of the industry’s big dogs jumped on the NACwagon, riding the buzzwords by simply re-branding a current technology as NAC.

And, that’s the culprit we’ll find if we dig to the root of our ‘Terminology Twists’ as I called them; a variety of words, definitions and catch-phrases from various NAC vendors that are incongruous with one another.

For the most part, our remote access vendors, switch and wireless vendors and firewall vendors (am I missing anyone?) all took their product, made a few cosmetic changes, a few verbiage updates and slapped a ‘NAC Sticker’ on the front.

Hence the Polymorphic Paradigm…  “a philosophical and theoretical framework”…  with multiple forms of a single product.

I suppose I’m fine with it… as long as it all works. But I would certainly prefer a world where we have some ‘truth in terminology’ so our customers can easily identify what products, technologies and features they’re actually getting. Until then- just check under the NAC Sticker and see what technology is behind it, and whether that will suit your needs (or not).

# # #

I started my career in IT many years ago and since that year have worked in enterprise IT for year and years.     Almost all of my odd career story evolves around working with end users, often advising, architecting and managing the complexity of large systems integration projects, from hands on implementation to strategic vision development.  My deep background is with Techrotech in network systems engineering.

A few years ago, years after I started my career at Techrotech, I grew a bit dismayed at enterprise software companies.   They would, for the most part, always come to us, the end users, and try to sell us large software packages.  Their sales and technical teams had very little domain knowledge of the problems they claimed they could solve - and they had little doubt that if we purchased their wares, our problems would be solved,

These software companies were keen on buzzwords and technology jargon but somewhat clueless on operational solutions or the challenges of implementation across a large federated organization with many powerful business units and “in name only” CIOs.  We often referred to these software sales guys, and their favorite systems integrators, as “drive by (or fly by) implementations” where they dump the software (and hardware) at your door and run like crazy!

So, I joined a very cool Silicon Valley company,  Nerwana Software, hoping to change all of that, or so I thought

Naturally, when I first came on board Nerwana , the entire organization, from executives to recent new hires out of school, heaped praise-upon-praise on my years of operational experience at Techrotech and elsewhere.   They cheered me on as I wrote papers and created slides on operational use cases and event processing solutions that the sales and solutions teams could take to market.   They sang my praises as I spoke to large audiences and evangelized their most innovative software and solutions.  They were pleased with the great reviews from customers.

As one would expect, I was destined to learn the face of the problems I experienced as an end-user “outsider,” now from an ”insider’s” perspective. 

One of the interesting challenges that surfaced at Nerwana was the “let’s export our culture and business model to the world” mantra, maybe better referred to as “if it sells in New York, then we must sell it the same way in Tokyo or Bejing!”

Also, I really was surprised to find out how dependent Nerwana was on the opinion of analysts.   When I was worked for the customers and end users, we rarely paid any special attention to the analyst’s opinions.   Sure, analysts provides a good data point, but that is all it was (or is), simply another data point.   

I soon found that software companies are often held hostage by “analyst chasing” which really was an eye opener for me, because we end-users, the people who actually buy the software, view analysts as mere mortals reading from the same foggy crystal ball as everyone else. 

Another one of the fasinating challenges I experienced at Nerwana was what some would call  “The Hero Culture.”  

I’ll elaborate on some these, hopefully interesting, observations and experiences in a future Page from Greg’s Diary.

Dear friend Opher Etzion responds to my post Betting on the SOA Horse with a discussion on how SOA, EDA and CEP are technically orthogonal, concluding:

“Event Processing can have different interactions with SOA, and when IBM’s announcements in this area will be available you’ll realize that there are different entry points. Event processing can also work in legacy and non-SOA environment.”

Richard Veryard, who also kindly reads my blog (and Opher’s blog) replies with Technological Perfecta where he opines,

“I think there are some mutual dependencies between these technologies, but they are what I call soft dependencies.”

Opher, Richard, you guys are technically right, but you are blogging orthogonally to the message in Betting on the SOA Horse.

First of all, my post was not a technical discussion, it was a discussion about business, marketing, timing positioning and the software industry in general. Therefore, it is a bit humorously orthogonal to reply to a marketing metaphor about investments, competition, software postioning and horse racing with architectual posts about technology and how they are related or interdependent.

In a nutshell, here is why….

Candidly speaking, despite what many analysts want you to believe, end users rarely build “SOAs” “EDAs” or CEPs”. End users have IT budgets to solve business problems with the most cost effective technology they can find; and they do not care (if they have a clue) what cute three letter acronyms have been created by analysts to describe momentum in the software market. Sorry, it is true really.

For example, I remember when I was in Tokyo where the very capable and conservatively risk adverse Japanese executives told me time and time again, “We don’t care about SOA we simply want to integrate our systems.” They were quick to remind me, “You guys in America must realize we don’t care what the western analysts, supported by software companies, say. They have a conflict-of-interest anyway and they are not end users. What we care about are mature technologies with solid reference clients and proven implementations.”

By the way, this is one reason I admire Japanese business so much. They are not impressed with handwaving hyperbole. They just want to see results. In other words, “Prove it, don’t just say it.” The devil is in the details, as they say. The Japanese are highly skillful at cutting through the smoke-and-mirrors. I think this is one reason the Japanese are among the leaders in so many industry sectors, but that is a blog story for another day.

To this point, if you are in front of customers and you are pushing SOA because your software company has “bet the farm” on positioning themselves as an SOA company, you are making a mistake. Three letter acronyms and technology jargon do not solve business problems. In fact, for the most part, they are a red-herring. The same is true of EDA and CEP. This was the main message in my post Betting on the SOA Horse.

How do I make such a statement?

Because for over 20 years I have worked as a consultant working on the opposite side of the table of hungry software vendors who come into our house (organization) tossing out buzzwords, acronyms, and jargon. My job was solving real business problems, not selling software. We used to wonder when all the scrabble and babble the software companies were tossing at us was going to turn into a business language that solves a real business problems easily, rapidly and economically. That day never came.

Then, I made a conscious decision to take a break from a long career of consulting to get an insiders perspective on, and perhaps even transform, the software industry. This experience, working for a software company, was an eye-opener, and one I am most likely not to repeat. I have never been interested in selling softare. I am interested in real business solutions.

Candidly speaking again, many software companies tend to live in “La La Land”.

They create go-to-market strategies based on jargon, buzzwords and three letter acronyms that have very little to do with understanding their customer’s business problems, risks, and culture. They spin and position and reposition in a land of smoke-and-mirrors happy to sell you a gold disk of “the-answers-to-all-your-problems.” They leave you the gold disk, and your business problem, as they drive away, looking at you in the rear view mirror as they count the revenue from their victorious campaign.

These same companies bet on jargon like SOA, EDA, CEP, BAM and they hedge their bets with different combinations of the above, the theme of my post Betting on the SOA Horse, which was not a technology nor architectural discussion, in any way.

Is it any real wonder why SOA has become, for the most part, complex, vendor-driven jargon barely making a dent in the real-world, whereas social-networking and other grass-roots user-driven technologies, most without trendy three letter acronyms, has left SOA in the dust for the past few years?