I read a question on one of the cloud mailing lists asking which of the federated authentication protocols (SAML, OpenID, Oauth, WRAP, etc) would win. My initial reaction was to reply, “Isn’t the question which ones won’t lose?” Okay, that’s snarky and perhaps a double negative, but I find it a rather dubious notion to think that there will be one winner. Aren’t authentication protocols like camera lens mounts? There are several types and all that’s important is that you can share lenses with the people you hang with? Why does there have to be a winner?

If you’re consuming a SaaS, it would seem like the service will support N protocols and you can either support one of those N. It seems like the big SaaS vendors will have some set of standards in place and it will take a couple of big customers to get them to expand that set. What’s it going to take for Force.com to implement something other than SAML?

For PaaS and SaaS, your organization is in control of the application, so you can handle authentication by whatever scheme you choose. If you’re working with some business partners, then you implement whatever protocol you both can agree to.

The protocols/mechanisms so far is only for user authentication. What would be helpful is if there were some way to enable authentication to include the cloud service itself. Cloud services all require some form of account information to do anything. If it’s a service like Amazon, there are also the private keys that have to be maintained, managed and passed to just gain access to the infrastructure. What all of the different delivery models have in common is the problem of authenticating to the cloud service. Is this a problem for identity management or just a (not so) simple credential management problem?

So, the question is not which one protocol wins, but which ones lose since you can only hurt yourself by implementing something that dies off. Then you can turn your attention to the problem of securing the authentication to the cloud service itself.

I had been reading about Gartner’s prediction that 1 out of every 5 businesses were going to dump all of their physical IT infrastructure when Sammy Migues sent me a thread from LinkedIn about it. The thread contained many of the common sense views about Cloud Computing that you’d expect: IT should be based on strategic value and should outsource the commodity pieces. That day, I was also reading about the Forrester survey that states that 43% of their respondants said that they had no interest in cloud storage and another 43% (perhaps the same 43%) had no plans adopt it.

Some of the difference in these two reports has to do with hype versus reality. I recall in “the naughts” that SOA was touted as a way for IT to bring business agility. Then all of the vendors got on the SOA band-wagon. Now it seems like Cloud has taken up where SOA left off in terms of hype. On the reality side, I wish I could tell whether the lag is because of people’s increased awareness of security (the optimist) or whether it’s a reflection of the sorry state of storage implementations (the pessimist).

I’ve lived in a bubble all of my life. My parents created a bubble to grow up in and then I wrote commercial software products. It’s only recently that I’ve stepped out of that bubble and seen just how messy the real world is. Yes, I’ve looked at bubbles from both sides now (sorry, but I couldn’t resist the not so veiled reference to Joni Mitchell).

Application software lives in a bubble too. Quite literally, the bubble itself are all of the network security controls, but there’s also all of that airspace inside. That air space is the set of invisible assumptions that the software is built on.

One of the assumptions that’s been on the top of my mind is “our software runs behind the firewall”. This isn’t an indictment of this statement, it’s true and there’s a wonderful, liberating set of assumptions that a designer can make. Where do those assumptions materialize in software development artifacts? For many of them, the answer is nowhere. They are passed on through the airspace because everyone knows them. There’s no need to write them down.

What assumptions exist in the security of an application when it gets ported to a cloud computing environment? Multi-tenant versus Single-tenant infrastructure – check. Externalization of IAM for SSO – check. The 20 other “well duh” generic security items that pundits (myself included) will dwell and pontificate on. What are the important ones? Damned if I know.

But you know and only you will know. Why? Because you’re inside the bubble and we’re not. So, start writing them down. And when I come in a pull out my generic (I called tried and true) solution for migrating to the cloud pull out that list. It’s that list of assumptions that stand between you and migrating your application to a the cloud.

The European Network and Information Security Agency (ENISA) published their analysis of security risks from cloud computing. It’s a well thought through paper and it complements the work on cloud security guidance being written by the Cloud Security Alliance. What I like about both the ENISA report and the CSA Guidance (I’m an author of one of the sections and, yes, I like my eating my own cooking) is that both documents take the point of view that Cloud Computing is going to happen and that security is going to have to deal with it.

There are certainly security risk for applications migrating to the cloud. These risks involve both security concerns such as the confidentiality of the information stored in cloud services as well the legal implications concerning the liabilty if a system is unavailable. This focus of cloud computing risks on the consumers of cloud services by both of these organizations seems justified. After all, how many companies are going to be cloud service provides?

Well, that’s what I thought.

Now, I’m thinking that if Cloud Computing really catches on (beyond everyone writing about it and attaching the word “Cloud” to any product or service that’s connected to a network) then I suspect that most “consumers” of Cloud Computing will want to be service providers too.

What caused this change in thinking was the article I read about how Larry Ellison “created” the network computer back in the 90s. The network computer really is what we call Cloud Computing today. Combine that with how SOAs evolve within an enterprise. They start as disparate web services, but then eventually the business units provide services that are their key data to the organization. With Cloud Computing it will be your business (not just your business unit) providing services (data) to other businesses.

The question is how you’re going to do that. I suspect that youll be exposing some kind of PaaS environment that your partners will write application-lettes in. These application-lettes are going to be doing the combining of data from your two systems. On which PaaS the application-lette runs is going to depend on which the amount and sensitivity of the data.

AI had a second coming in the 80s, aren’t we ready for a second coming of “The Internet is the Computer” in the 10s?

Technorati Tags: software security, cloud computing

Warning: a fair amount of cynicism occurs in this post.

Some of my buddies have been exchanging ideas of what keeps us interested and one friend was thinking about how he could use a user’s Facebook login on his site. This nudge along with some work I’m doing with federated identity and Amazon SSO all have brought this federated identity stuff onto the foreground thread in my brain.

It’s all very interesting stuff and I think there’s some great technology behind all of this. I’m not worried about the technology part. It’s whether the technology can ever get implemented that worries me.

Why? Well on the internet audience and the audience demographics are the currency of the realm. If there’s federated identity, then providing all of my identity information to the relying part is redundant. There’s no way marketing is going to let THEIR site be the relying party. Marketing will want THEIR site to be the IdP. That’s because they want the users to sign up and provide all of the contact and demographic information since that’s the only business model that has been proven to work last time I checked.

I can imagine a conversation going like this:

Me: We should implement federated identity so our users don’t have to log in a gazillion times.
Marketing: Good idea.
Me: Whose identity should we use? LiveID? Amazon?
Marketing: Huh? What do you mean? Ours of course. We need the user to sign up to give us their email address.
Me: Well, we can get that. It’s part of the claim that we’ll get as part of SAML.
Marketing: Sam who? When does the user give us his email?
Me: They don’t give us the email directly. They give it to the identity provider and then…
Marketing: No, no, no, no (just like your mom used to do) – this doesn’t sound like a good idea…

So maybe all we really need is an identity selector and we’ll be the digital equivalents of the janitor with the massive key ring on our belts.

Technorati Tags: federated identity, cloud

My colleague, Ben Walther, pointed me at this post about Cloud applications and Web-app security by Rich Mogull. The title is “How the Cloud Destroys Everything I Love (About Web App Security)”. The post talks about running Web apps on a cloud platform like EC2. I’m not sure I buy into everything they say.

First, I’m not sure what Rich means by a “Web App”. To me, the term Web App describes an n-Tier application with a browser front end and some kind of backend SQL database. There are maybe some web service calls thrown into the mix. It’s the kind of applications that everybody’s been writing for the last 10 years. So, what’s going to change if I’m running this same application architecture on infrastructure that I’m buying as a service? Sure, I have to worry about all of the inter-machine communication channels because I don’t have the nice data center supplied network security. But what else?

Now when we move to cloud-based applications (environments like AppEngine or 10gen), ones that take advantage of the highly distributed nature of the code as well as the virtual environments, then we have changed the application architecture. I buy that security for these apps changes, but it’s no longer “web app” security. In these cloud-based applications, there are some different fundamental assumptions about the architecture, like no transaction serializability. But for these legacy web apps running in a virtualized infrastructure, I’m less convinced that there is a drastic change.

There are a couple of specific points made in the article that I don’t agree with:

Secure development (somewhat) breaks because the underlying platform can’t be locked down.
Just because you can’t lock it down yourself doesn’t mean that it can’t be locked down. This seems like an argument for secure deployment breaking and not secure development. Even then, the PAAS or IAAS may actually lock the platform down better than you can. It does shift the problem from looking at technical artifacts (configuration files, patch logs, etc) to looking at legal and audit artifacts (SLAs and certifications).

Static analysis tools (mostly) break.
The contention is that there’s less code you program yourself. I don’t see this as true for IAAS platforms like EC2, how much code is provided that you really need to worry about. Besides, static tools are language based and if it’s the same language, it doesn’t really matter whether it’s running on a virtual OS or a physical one. The change that breaks static analysis is the move to dynamically typed languages.

My take is that the infrastructural changes of a cloud computing have a more drastic effect on an organization’s ability to deploy securely. Being able to develop securely is based on the application architecture. I really see these as independent levers rather than a single “cloud” lever.

Technorati Tags: Cloud Computing, Security

A recent thread about hardware and software requirements for development on the Google cloud forum made me wonder what cloud computing will mean for development, test and production environments. There are a lot of really interesting questions here, but my mind got stuck on the relationship between development and production. I’ve always been amused at the IDE feature that touts instant deployment from the developer’s desktop to the production system. Wearing my security hat, I should use the word “horrified” instead of “amused” because I can think of no worse model for deployment than developer-to-production.

I came to the conclusion that deployment of cloud-based applications will require much more engineering rigor to assure the security of the deployed application. There will, of course, be variation in the amount and type of rigor based on the type of cloud the application is being deployed to. For example, deploying to a platform as a service provider will be different than deploying to a infrastructure as a service provider where the later will require a lot more rigor. But, given the amount of manual steps involved in most of the deployments I see, I’m very worried that deployment automation will be overlooked as a required security control for cloud-based apps.

Large companies will have tools like Opsware and Bladelogic for their existing data centers, so they have a base of automation to work from. It’s the medium-large and medium sized organizations that I see as needing automation help to secure their deployments. I think these companies will be adopting cloud-based applications for their cost advantage over internally owned and managed infrastructure. But these organizations have a much more collegial relationship between development and operations and moving to operations to a service model will break these relationships. It’s the same problem that companies face when moving parts of development offshore. The solution for development is more formal API contracts and specifications. With operations, automation is an excellent way of formalizing the “API contract” between development and operations.

Security will have its part in this equation as well. All of the assumptions about who can do what with which parts of the application, who you can trust and with what credentials will have to be re-evaluated. Some of my colleagues would argue that this is the least of our worries. I would agree, but given the lack of a shared understanding of cloud security, I think that these operational concerns need to be on the list.

My buddy Jim Menard sent me this link when we were talking about comments Don Rippert made about the futility of MDA.

Don Rippert’s comments were (in summary) that by the time you got to any level of specificity in the model that the complexity of the models made them harder to follow than code.

I’ve been using Enterprise Architect to reverse engineer code by loading the code into EA and looking at the generated UML. I’ve given up and gone back to emacs.

A recent discussion about the virtues of the Chief Programmer method motivated me to re-read “The Mythical Man-Month”. What a great book. I read it while on vacation and kept on saying to my wife “Why don’t they make all computer science and software engineering undergrads read this book?” When I came back, I asked some of my co-workers if they had read the book. The only ones that had were “old guys” (like me) and one “young guy” who attended UNC where Brooks taught. That’s sad and I encourage everyone young and old to read this book.

The book, however, is a little dated. To prove one of his points, Brooks describes as “extravagant” the use of and additional “10 bytes” to implement leap year support in OS 360’s date code. Now, 10 bytes “back in the day” was indeed extravagant, but for a programmer that has been brought up coding in today’s environments, 10 bytes is less than the guy’s email signature.

As I pondered these 10 bytes, I reminisced about some code I had to maintain in the RSTS/E kernel. The code was:

CMP (PC), 4(SP) ;Is 4 off of SP 4? Saves 2 bytes

This took me and another guy more than a couple of minutes to figured out, but sure enough it saved those precious two bytes. So, just how precious were those two bytes?

Adjusting for the fact that these two bytes were on a 16-bit architecture and today’s machines are 32-bit, I figured that those two bytes are equivalent to 128K. What would you do to save 128K in a space sensitive area of your system or perhaps that application you’re writing for your mobile phone?

So, what does this have to do with software security? Nothing. But, after all, I was on vacation.

This entry started as an email to a co-worker: Will. I’ve edited to make it a bit more readable, but in an attempt to blog more often and less formally, I’m only applying the thinnest editing veneer. We were discussing whether (again) moving entitlement/access control decisions out of the application code really made sense. Will was concerned about not making the developer responsible for implementing access control for an interface. I’m putting words in his mouth, but how can one “build in” security if the responsibility for one of the more fundamental security controls is taken away from the developer?

The notion of externalizing the access control is spot-on from a design standpoint. There are many reasons to externalize and one can argue that many of the problems with web application security is that the auth/auth got shoved into the application and the application developers were not qualified to write such code.

I think what was making Will nervous was the question of WHO makes the decisions when configuring this externalized mechanism. It’s also the case that WHEN do these configuration questions get handled. The answer to date is that there is some sys-admin or app-admin that does this after the application is deployed.

Historically, this hasn’t been done very well and/or the RBAC systems put in place to configure and manage such auth decisions have been notoriously difficult to administer at scale. I will, however, say that one of the arguments for externalizing the mechanism is that the job of implementing auth/auth requires more than the PDPs/PEPs in the app; it’s all of the additional software for managing/updating the PIPs where the bulk of the work resides in building a robust access control mechanism. Again, the app-dev guys aren’t the best person to write all of the management software and you wind up with the problem where administrative functions is just a series of configurations handled through a command shell or your favorite editor.

This still doesn’t properly answer the question of WHO. Admins don’t have the knowledge to properly configure and the developers don’t have a proper notion of who should be using the interfaces they create.

This is really an architects job, but while the architect has the breadth of knowledge to make the decision yo (trying out this new gender-neutral pronoun) lacks the tool to understand the actual interfaces that exist. The architect will have pre-defined about 80% of the actual interfaces, but the implementers will have created others to solve implementation level problems. So, 20% of the interfaces will be entitled without much thought.

So, let me make another point of externalizing the auth/auth mechanism. That is what we need here is a tool that can turn all of the code into (UML) descriptions of all the interfaces. We need to decorate that list with the entitlement data, but we can only do so if there is a canonical way for the tool to read the entitlement information about said interface. If we can do this, now we’re cooking with gas since we could then write some kNN-like algorithms to compare each interface with other interfaces like it so we could see where there are potential, logical inconsistencies.

Technorati Tags: access control, entitlements, design, architecture