Salesforce.com’s Dreamforce conference takes place this week in SF. Billed as “The Cloud Computing Event of the Year”, the conference kicked off with a keynote by Benioff while people wearing puffy-white jackets and holding giant helium-filled cloud balloons stood outside.

Benioff announced partnerships with Facebook and Amazon.

Part 1: Force.com apps will be able to run on Facebook and leverage the Facebook users’ social network. An example shown was integrating “My Starbucks Idea” into Facebook. If a user submits an idea through Facebook, their friends can see it, comment or be prompted to submit their own.

Part 2: Force.com applications can now use Amazon’s cloud hosting services in addition to the public Force.com sites.

This is smart and a surprisingly non-megalomaniac way of doing things. Instead of trying to own the entire cloud stack (hmmm – someone just made a very different announcement), Salesforce looks like it’s focusing on what it does best – enabling application development in a hosted model. And letting Amazon take at least some of the future blame for any outages/interruptions in service (anyone who has Salesforce can say amen to that). That is smart.

If somebody asks you "Can you have a secure cloud-based service?" - you need to ask back "What do you mean by "you"?" Seriously! Let's go back to the old joke that "the only computer that is 'secure' is the one that is turned off, cemented into a big concrete cube and stored in a locked room." But whose room? Do you own the room where the aforementioned concrete cube is stashed? No? Then maybe it is no longer 'secure' ... Think "concrete cube in the clouds - then BAM!" :-)

Joking aside, if you think that a system that is located somewhere remotely (you don't control physical security) + Internet accessible (you don't control network security) + neither written  nor audited by you (you don't control application security) can be secure, than yes, most certainly you can have a secure cloud-based service.  This also reminded me about this post by Richard where he classifies people into "two camps: those who trust their products to operate as expected and those who do not."

Now, let's review some of the issues with security of cloud based services.

First, is there public vulnerability research that made MS IIS and OpenSSH (and OpenBSD) the paragons of software security? No, this part is completely screwed up today as only criminals are "allowed" to do vulnerability research of cloud based-services (and web applications).  Comparison here is not in favor of "the clouds," and "legacy" software approach wins hands down (want trusted apps? go audit them!). To remind yourself what the world looked like without public vulnerability research, think back to early 90s: "hot new exploit - telnet as 'root' without any password" (this is where web security stands today, pretty much).

Second, can you make sure that only you will see the sensitive data (or even regulated data: PHI, credit cards, passwords, financials, etc)? Maybe, if you take care of it. As Mike R  puts it : "Basically, you can't be sure anything is secure in the cloud, so that means you have to secure it yourself. That means building your applications with some semblance of data protection [...] But ultimately if you can't prove your data hasn't been tampered with and that it's open for anyone to steal, then I suspect your auditor may have a bit of an issue with that."

Third,  can you log and audit access to your information, stored and processed somewhere in the cloud? Maybe, if you chose the provider that allows you to do it. For example, I hear that Salesforce.com access logs are good enough to enable most things you can do with OS logs. Otherwise, well, keep begging them to build it; there is no appliance you can buy to plug this hole.

Finally, if we are insane because we use software, what about cloud services?  Sorry, multiply that insanity by 10x. Replace today's mantra "I trust my software vendor" with "I trust my cloud provider, their software developers, their outsourcers (if any), the other vendor they mashup with, my ISP (and its ISP, and its ISP,  and its ISP, etc, etc), my cloud provider's ISP (and its ISP, and its ISP, etc, etc, etc)  and ... oh, wait ... and your software developers who wrote the code that connects to the above in-the-cloud service." Cool, isn't it? :-)

This paper also reminds us about the business angle: "Remember that the storage provider has less to lose than the customer"  [that is you, BTW]. At this point somebody has got to ask "is that dirty C-word hiding somewhere here? Is there a compliance angle?" You bet. And it is "simple", really: just compare a) and b) here:

a) you manage a system that contains financial records (SOX anybody?), you screw up and they are lost OR you don't screw up and they are OK (not lost)

vs

b) you DON'T manage a system that contains financial records (SOX still?) - it is in the cloud, you DON'T screw up and they are still lost since your cloud provider screws up.

Who do you think will go to jail?  And don't even get me started on the breach disclosure law angle here (if they lose your data, than you are in violation of SB1386 - that is at least my guess ...)

By now, it should be painfully obvious to any and all of my readers that "in the cloud services" are indeed the future of IT! :-) Yes, and security is a great career - with no shortage of challenges to overcome or tall peaks to climb ... now and ever. That is why I love it.

“Security in the cloud” just got more complicated with the introduction of “Cloud Mashups”.

What Do You Get When You Cross Salesforce.com and Amazon S3?

The answer we are told is Appirio Cloud Storage - a fully integrated Salesforce.com add-on that uses Amazon’s Simple Storage Service (S3) to store larger files. Previously, Salesforce.com users were limited to 5MB file uploads.

Read this quote from Appirio and think about it from a security perspective:

We’re excited not only about the service itself, but also what it represents. It shows where the industry as a whole can head - as the platforms mature, there is a substantial opportunity for ISVs to tie together the different clouds and provide offerings that extend and fill in the platforms themselves. In traditional enterprise application integration (EAI), packaged integrations were difficult to commercialize. The permutation of versions and customizations created and “n times n” problem, making it too expensive to create something “packaged” that appealed to more than a very small number of customers. But in the cloud, because SaaS providers commit to stable interfaces - Salesforce has maintained backwards compatability for more than a dozen revisions of its API - “integrating the cloud” can become a new class of solution.

From a security risk assessment perspective, you now need to factor in 3rd parties that hook into your “primary” cloud providers API.

If your company goes with Appirio, company data is now stored in Amazon S3 buckets paid for by Appirio, instead of storage paid for by Salesforce.com. This means your data is actually split across both providers (!) - old attachments and CRM data with Salesforce.com and new attachments with Appirio (if someone from Appirio is reading this and can say differently, please do).

As it happens, Salesforce.com already uses Amazon for computing and storage so its the same back-end storage. But what happens when another cloud storage provider pops up that offers a better deal? Lets say salesforce.com stays with Amazon S3 but Appirio migrates to the new player to attract more customers.  [Just to be clear, not picking on Appirio here - this applies to *any* ISV - particularly those that store data somewhere else in the Cloud].

Multiple cloud storage providers for a single app, raises some issues.

• Is ISV obligated to tell you they are migrating to a cheaper cloud storage provider? (think cross border data transfer issues).
• What security ‘certification’ will take place of the new provider and what visibility will you have of that?
• How much notification do you get before the switchover?
• If you don’t want to go with the new provider, but that is the only supported option, what happens to all your data? Even if we *assume* an export function is provided you still need to find an alternate ISV that has coded a compatibility layer to access your existing data. If you can’t, where do you export the data too? Will we have ‘frozen clouds‘?
• What integrity checks take place to ensure data was properly migrated over?
• When the migration happens, what clean-up happens at the source? (can anyone say forensic wiping?). What about any backup tapes or off-line copies? Who is responsible for making sure those are wiped/destroyed?

Suddenly your cloud storage arrangements have gotten more complex and thus, less secure. Security issues aside, how does an agile business cope with this? With multiple providers, data portability becomes a real issue.

And we haven’t even dug into the API level security issues yet! (yeah, you get to assess that too!).

As an Information Security community, we have to start figuring out some of these issues before we find our options severely limited…

What do you think?

I received an email today from Amazon Web Services (AWS) Support announcing new support offerings. One item that caught my attention is the new Service Health Dashboard.

The dashboard is pretty standard fare - traffic lights to show availability for each Amazon service with a historical view available at the bottom.

This is good and all but where is the security dashboard? I’d like to know their “security service” is operating normally. Are they “hacker safe” ;-)

I can dream right?

Users of salesforce.com are not dreaming when they surf over to trust.salesforce.com. In addition to the - dare I say it - “expected” service availability dashboard, they display recent security alerts to raise awareness.

Thats definitely a “good thing” - as far as it goes.

For larger organisations that already use security metrics to track the effectiveness of their security program, this isn’t going to cut it.

Cloud providers, are you listening?

What security metrics would you expect to see from your cloud provider?

I don’t Twitter.  

But….

Then all the Twitter jokes on Geek and Poke got my attention.

Then, again, I started thinking ….

What if we could process all those Twitter events, all the millions of answers to the little Twitter question:

What are you doing now?

What if your entire sales force Twittered?

Maybe a slick Twitter alliance with SalesForce.com?

Then, we process all the Twitterevents in Twitterspace.

What could we discover? 

Twitter Trends?   Twitter Demographics?    Twitter Agent Behavior?

Maybe Twitter can merge with Simutronics for real-time gaming with Twitterites?

To add more  substance to this, let's review some of the key requirements for a log management platform:

• Overall platform requirements (good intro here): having an access API is central to this.
• Data access:  in case of  a log management platform,  API should let users receive their log data in either raw or  processed (i.e. "parsed" or tokenized) form.
• API for control: log analysis is not just searching,  but also includes alerts and other things that sometimes needs to be tuned. API should allow that.
• Also, platform should enable broad, non-siloed approach to log management (silos are evil!) and thus allow any type of analysis and data access: not security-specific, not troubleshooting-specific, but broad, cross-domain approach, suitable for many types of users, from system admin to a CIO.

Finally, you know what? "Developer-centric ethos"  sucks - I would much prefer a "user-centric ethos,"  since ultimately a platform is not built for people to play with it (like his? :-)), but for the end-users to do something useful with it and to solve problems that they have ... Development based on the platform is indeed critical - but not as critical as solving a problem at hand!

Technology aside, OpenID will greatly help with reducing and removing the legal obstacles in the way of  identity federation’s proliferation. When payment-grade, commercial, and trusted identity provider service becomes a reality – VeriSign’s joining the OpenID camp clearly points in that direction – and software-as-a-service companies (like salesforce.com),  accept OpenID authentication from these trusted identity providers, then enterprises can truly start thinking about outsourcing password management identity management processes. When required, strong authentication integration with OpenID can rely on VerSign’s VIP or other vendors’ strong authentication acceptance network.

In addition to the above factors, resolving DNS spoofing vulnerabilities and productized integration with SAML and other federation technologies will be key enablers in OpenID’s success and promotion from the current low-value (e.g. blogsite) authentication usage, to becoming a full-fledged, enterprise-level federation solution.

Over those months, I’ve had several things that I *wanted* to blog about; but just never made the time.  One of the reasons is that, for the most part, there has been little to be truly excited about in the industry as a whole.  “Nothing new under the sun;” and all of that…  At least that’s what it seemed like to me.  But now things are starting to settle down and I’m having/making time again to get plugged back in.

So today I was reading Martin’s show notes and came across the SalesForce.com data breach story.  And, behold, I felt the urge to write again.  As I’ve been reading the news over the past few months, I have been thinking to myself that we have a problem…  Breach notifications are being reported so often now that they seem to be just creating a constant “white noise” drone.  Sure, there are the standouts like TJX — but really, most are just more of the same.  To the extent that I fear the public will just end up being numb to the notifications, and ambivalent to the poor practices that are the cause.  Each new notification just being another drop in the ever-deepening ocean of lost records.

But the SalseForce.com story is different due to the “spear-phishing” aspect.  And it highlights multiple security problems.  Two in particular are of note.  1:)  Users are still susceptible to phishing.  Yeah, I realize that this was a highly-targeted “spear-phish” — but the “don’t click the link” (or at least verify the link) adage should still hold; and 2:)  data breaches, even those which do not contain what we would consider PII, are dangerous.  Here, the data is reportedly being used to create additional phishing emails (some intended to drop malware such as keystroke loggers, etc…), bogus invoices, and so on.  In other words, the SalesForce.com breach wholly revolves around social engineering.

I think that it is notable that these issues revolve around end-users and, outside of any emails intended to dropped malware, cannot be addressed solely through technical means.  So, we again come back to end-user training and awareness.  It is imperative that we, as an industry, get a handle on how to better address this in our organizations.  It’s clear that what most companies are doing is just plain broken.

Here are my thoughts:

Engage employees in ways that are relevant to their life as a whole.  Address the “What’s in it for me?” question.

Explain the “WHY” behind seemingly obscure security policies or procedures.  As is made clear by the SalesForce.com incident, we can’t simply expect technology or process to address all potential security issues.  Instead, we need our front line defenses to act as living firewalls.  Thinking on their feet and able to apply an informed mindset across multiple situations.

Let employees know that it is part of their job – just as much as any other duty that they do.  (Yeah – I realize that mentality must be driven from the top down).  Make it part of the performance evaluation; so that they are aware that the will professionally advance or stagnate based on how seriously they take their duty to protect information.

Make it fun.  Find ways to reward the folks who are doing it right.  Let that encourage others to improve.