Published: 05 Mar 2009
Not long ago, a researcher at the pharmaceutical company Eli Lilly needed to analyze a lot of data fast. If the results turned out as he believed, the company could have a world-beating drug on its hands.
The only trouble was that he would need 25 servers to crunch the huge volume of data, and he knew it could take up to three months to get approval for the investment. In an industry where the cost of delaying a product is estimated at $150 per second (yes, per second), that three months' wait would be very expensive indeed.
Adrian Seccombe, the company's global head of security, explains: "He went to a tame IT guy who'd been playing around in this thing called 'The Cloud'. The guy got out his credit card, plugged it into Amazon Web Services, and had 25 servers up and running in the cloud within an hour."
They then realized they'd built the servers incorrectly so they had to take them down and start again. The second time, it took them 40 minutes to get the servers up and running.
"Within two hours they were crunching the data. The research time had suddenly collapsed from three months to two hours," says Seccombe.
And there is more. When they realized the analysis would not be complete by the time they wanted to go home, they were able to crank up the power, and bring on more servers to speed things up. "They wanted to get the data back from the cloud as they felt a little uncomfortable leaving it out there overnight."
They completed the task, and were given a bill from Amazon for the princely sum of $89. At $150 per second, a three-month wait would have cost more than $1 billion.
The cost comparison is mind-boggling and demonstrates the sheer power of the cloud computing concept. But for Seccombe, the example also underlines some of the problems with the model too.
"They repatriated the data results, and did it securely over a secure line that goes end-to-end into the Amazon cloud. It was secure and quick."
Or was it? How could they prove there was no trace of their data left in the Amazon cloud? They had to take Amazon's word for it.
It is just one of many questions that are now being raised with the advent of cloud computing, software-as-a-service, and the new collaborative model that relies on companies sharing their digital assets.
And it is why Seccombe, wearing his other hat as a member of the Jericho Forum, a security think-tank, has been working recently with others in the group to come up with some kind of framework to chart how it can be done effectively and securely.
The result of this work, due to be unveiled officially in March, is a three-dimensional cube that attempts to map out in graphic form the key decisions that companies will have to make when deciding which tasks could be safely consigned to the cloud, which should be kept under lock and key, and how you tie all the various ways of working together.
For the last five years the Jericho Forum has been challenging conventional thought about information security and mapping out the requirements of a "de-perimeterized" world where solid boundaries are replaced by mobility and collaboration between organizations.
Last year, Jericho laid out its Collaboration-Oriented Architecture, which defined how systems could work together without jeopardizing security. Now it is going further to map out the security requirements of cloud computing. The results of this latest exercise raise some challenges for the security industry, but also outline some interesting opportunities for those with the vision to seize them.
The main message of the group is that the cloud can incorporate a variety of approaches, according to the level of control you need over a process.
The cloud computing collaboration model looks like a Rubik Cube with four faces on each side -- thereby creating eight separate sub-cubes that represent different types of working.
The three dimensions of the cube are:
- Open/ proprietary
- Perimeterized/ deperimeterized
The cloud computing model is intended to help companies categorize their business processes and ultimately plan the kind of systems architecture they are going to need going forward.
"It's a mistake to see the cloud as one thing," Seccombe says. "You can have internal proprietary perimeterized clouds, and you can have external, open, deperimeterized clouds.
"Inside Eli Lilly, we are trying to decide where we want to do what business processes. For example, bringing together the ingredients for a pill -- we probably wouldn't do that with an open, external deperimeterized cloud. That is more likely to be proprietary, perimeterized and internal, still using cloud technologies possibly, but I need more control over it."
The key, going forward, is to build efficient and secure interfaces between the various sub-clouds so that business in the cloud can work in a seamless way, and create the necessary services to make it happen.
One of these, for example, could be an independent service to check the repatriation of data from the cloud once a task is finished. "It's not that we don't trust Amazon, but it is a question of separation of duties," he says. "You don't want the auditor to be the one who's providing the service."
Working up the 'cloud layers'
Given the huge advantages of working in the cloud, the goal now is to see how much work you can safely entrust to the cloud as a whole.
Jericho envisages this potential as a series of layers as follows:
As companies move up the stack, and entrust their infrastructure, platform, software, and so on, to a cloud-based service, they can achieve what Seccombe describes as 'abstraction': "Abstraction means that you don't really care what's going on beneath, because somebody else is looking after it for you, and will deal with it in a responsive manner."
He admits that most cloud activity is down at the infrastructure and platform level (as with Amazon Web Services) or with software (as with Salesforce or Netsuite). But he cites one example of Value-as-a-service, which came from personal experience.
When looking for a new battery for his Blackberry, he clicked on the Amazon website, which brought up five shops that were selling the battery. He chose a shop and ordered, and the battery quickly arrived in an Amazon box. "Amazon brought to me the value experience of getting that battery, but I can't remember which shop I bought it from. This was my first experience of value as a service. I did one click and got the battery delivered the next day."
The example underlines the move towards customer-centric computing supported by increased collaboration in the cloud. And it is not just about shopping.
Seccombe cites the Patient Like Us website where people with various complaints can compare notes. For a drugs company, something like that would present huge opportunities to get patient feedback, but only if the right controls are in place.
And there's the rub. Cloud computing is very appealing, but diving in without the right level of security in place is a recipe for disaster. As Seccombe says, you can't bolt on security after the fact. "If you enter the cloud naively, then you lose sight of your data. You lose control," he says. "That's why we are trying to get this done up-front."
The future of cloud computing security
Cloud computing could have a huge bearing on how we do IT. Even if companies continue to run their own systems in-house, they might develop and test applications in the cloud rather than buy their own systems for the purpose.
Off-site disaster recovery centres will also start to look like a waste of money when cloud-based services can offer the necessary back-up without the huge up-front cost.
But the services need to be easier to use. For example, the Eli Lilly researchers had to configure their own servers manually, but in future that kind of service could be automated with new servers coming on stream automatically to cope with the demand.
Identity and access management will also take on a new importance as more collaboration takes place in the cloud, and where collaborative activities may be very short, lasting minutes rather than years.
"The old model, which assumes that everyone inside your silo is trustworthy and where you build an Active Directory for those players to use resources inside your organization, is dead or dying. We have to find ways to change it," says Seccombe.