Perimeter
7/25/2011
08:03 AM
Jim Reavis
Jim Reavis
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail
50%
50%

Future Clouds: Centralized Or Decentralized?

The trend might be moving toward putting more eggs in fewer, more secure baskets

Risk concentration is one of the issues to consider as cloud computing evolves. The economies of scale that have brought cloud computing to where it is so far seem to point to further consolidation and the growth in size of a smaller number of mega data centers.

When Vivek Kundra, the outgoing federal CIO, spoke at the Federal Cloud Strategy at our CSA Summit earlier this year, my favorite slide in his deck compared the federal government to IBM in data-center consolidation. Whereas both had several hundred data centers in 1997, the federal government now has more than 2,000, while IBM has 12!

It seems as though the trend is toward putting more eggs in fewer baskets -- albeit more efficient and I believe more secure baskets. But is that truly the case? I can see Moore’s Law and management efficiencies continuing to support this trend, but I think the wild card is the cost of energy. It could very well be that this is the variable cost that upsets the apple cart, and the cost of cloud services might track the cost of energy over time.

In the U.S., many data centers have been built in eastern Washington and Oregon to take advantage of cheap hydroelectric power. It is easy to imagine a variety of events that could radically change the energy cost basis of a data center.

Greater decentralized clouds could mitigate this issue, and it is not hard to imagine more sophisticated versions of the cloud-brokering solutions of today helping customers move workloads around to lower energy cost data centers. If you take this idea to its extreme, the compute power of a few million smartphones could be pretty tremendous, and the energy costs are zero. Is it possible that the future of cloud will be a significant amount of mobile clouds?

Management costs could be higher for something like this, but there have been very good examples of well-managed distributed compute networks for years; my favorite is the botnet.

I don’t know whether this is the future, but I think we need to plan for this being a possible outcome. Clouds might include a lot of untrusted, low assurance infrastructure, and thinking of our security layers in completely virtual terms is very healthy. Building security into the applications, abstracting between the different technological layers, protecting the data wherever it might go, and instrumenting every entity (virtual machines, hypervisors, data stores, users, etc.) with identity management and nonrepudiated logging technologies is essential.

None of us really knows what the cloud might look like tomorrow, so think about implementing security in a way that allows us to take advantage of its future -- or some alternate futures.

Jim Reavis is the executive director of the Cloud Security Alliance, and president of Reavis Consulting Group.

Jim Reavis is the President of Reavis Consulting Group LLC, where he advises organizations on how to take advantage of the latest security trends. Jim has served as an international board member of the Information Systems Security Association and was co-founder of the ... View Full Bio

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-2595
Published: 2014-08-31
The device-initialization functionality in the MSM camera driver for the Linux kernel 2.6.x and 3.x, as used in Qualcomm Innovation Center (QuIC) Android contributions for MSM devices and other products, enables MSM_CAM_IOCTL_SET_MEM_MAP_INFO ioctl calls for an unrestricted mmap interface, which all...

CVE-2013-2597
Published: 2014-08-31
Stack-based buffer overflow in the acdb_ioctl function in audio_acdb.c in the acdb audio driver for the Linux kernel 2.6.x and 3.x, as used in Qualcomm Innovation Center (QuIC) Android contributions for MSM devices and other products, allows attackers to gain privileges via an application that lever...

CVE-2013-2598
Published: 2014-08-31
app/aboot/aboot.c in the Little Kernel (LK) bootloader, as distributed with Qualcomm Innovation Center (QuIC) Android contributions for MSM devices and other products, allows attackers to overwrite signature-verification code via crafted boot-image load-destination header values that specify memory ...

CVE-2013-2599
Published: 2014-08-31
A certain Qualcomm Innovation Center (QuIC) patch to the NativeDaemonConnector class in services/java/com/android/server/NativeDaemonConnector.java in Code Aurora Forum (CAF) releases of Android 4.1.x through 4.3.x enables debug logging, which allows attackers to obtain sensitive disk-encryption pas...

CVE-2013-6124
Published: 2014-08-31
The Qualcomm Innovation Center (QuIC) init scripts in Code Aurora Forum (CAF) releases of Android 4.1.x through 4.4.x allow local users to modify file metadata via a symlink attack on a file accessed by a (1) chown or (2) chmod command, as demonstrated by changing the permissions of an arbitrary fil...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
This episode of Dark Reading Radio looks at infosec security from the big enterprise POV with interviews featuring Ron Plesco, Cyber Investigations, Intelligence & Analytics at KPMG; and Chris Inglis & Chris Bell of Securonix.