A polemic on the issues and challenges confronting us in the domains of "security" and risk management, as system architectures move to include the Cloud. Keep an eye on the speaker Notes for each slide -- there's stuff in there.

1. Risk and Security in the Enterprise Cloud

3. Do you know what a “zombie” is?

4. Really?

5. How do YOU know that you are not a zombie?

6. Did you know that there is a whole culture of ivory tower folk who spend their days trying to answer that question? http://consc.net/neh/papers/dretske2.htm http://en.wikipedia.org/wiki/Fred_Dretske http://philsci-archive.pitt.edu/archive/00002546/01/caatkg.pdf

7. Hmm. Interesting. But, so what?

8. Do you know what the Principa Mathematica is?

9. “ It is an attempt to derive all mathematical truths from a well-defined set of axioms and inference rules in symbolic logic.” http://en.wikipedia.org/wiki/Principia_Mathematica

10. http://en.wikipedia.org/wiki/Bertrand_Russell

11. Did Russell succeed?

12. No.

13. In fact, he not only failed, his failure provoked one of the most profound insights our species has ever achieved…

14. Kurt Gödel’s Incompleteness Theorems http://en.wikipedia.org/wiki/On_Formally_Undecidable_Propositions_of_Principia_Mathematica_and_Related_Systems

15. http://en.wikipedia.org/wiki/Kurt_Gödel

16. Right up there with evolution and relativity, on the “wow, this is a big deal” scale.

17. So, what did Gödel figure out?

18. No formal system extending basic arithmetic can be used to prove its own consistency.

19. Hmm. Interesting. But, so what?

20. No formal system extending basic arithmetic can be used to prove its own consistency.

21. Formal system extending basic arithmetic .

22. Umm, dude. That would, eh, be a computer?

23. Because computing is a mathematical model…

24. Computer people tend to assume that such models are not only necessary …

25. But also sufficient . In other words, they assume that knowing the model means absolute control over the results.

26. http://en.wikipedia.org/wiki/Kurt_Gödel LOL!

27. Consider the classic way of defining “risk”…

28. Risk exposure (RE) = probability(loss) * magnitude(loss) http://books.google.com/books?id=0RfANAwOUdIC&pg=PA800&lpg=PA800&dq=risk+exposure+re+formula&source=web&ots=pENn1no-zn&sig=Xe72BRymob2ftXlp4CciUr-ly-Y&hl=en&ei=QquNSfLdMob00AXB4OGcCw&sa=X&oi=book_result&resnum=5&ct=result (The Handbook Of Information Security)

29. That formula is not wrong, but…

30. Some people assume that they can leverage it, and others like it, to “prove” that a complex system is “secure”.

31. They take comfort in arithmetic.

32. http://en.wikipedia.org/wiki/Kurt_Gödel LOL!

33. And recall…

35. What’s “the Cloud” got to do with this?

36. It increases the complexity of the overall system.

37. Makes an existing problem more urgent .

38. Ludwig Wittgenstein, a fierce critic of Principa Mathematica , conceded that it was useful, but only in the small.

39. To the extent that naïve use of the Cloud scales systems up beyond “small”, it forces us to confront a problem we may have been able to ignore.

40. http://www.flickr.com/photos/rachels_secret/220269351/

41. So. What to do?

42. There are essentially two approaches: 1) try to build out the existing, Russellian, “defense in depth” techniques.

43. http://en.wikipedia.org/wiki/Kurt_Gödel LOL!

44. Or 2) find ways to design systems that cope gracefully with uncertainty.

45. This also implies finding ways of decomposing systems, and applying techniques to cope with risk and uncertainty, in the small.

46. Not this…

47. http://www.flickr.com/photos/peterpearson/347124844/

48. But this…

49. http://www.flickr.com/photos/euthman/2989437967/in/set-72057594114099781/

50. I know what I’d bet on.

51. Is anybody trying to do this?

52. Yes! Good examples abound.

53. The U.S. DOE published an excellent report in December: “A Scientific Research & Development Approach to Cyber Security”. http://chas.typepad.com/dli/2009/01/cyber-security-rd-needs-for-doe.html

54. The Jericho Forum, part of The Open Group, is doing important work in defining models of security and risk that don’t ignore Gödel’s LOL. https://www.opengroup.org/jericho/about.htm

55. And, in a shameless plug, CSC’s report on “liquid security” contains lots of information, particularly in the section on “Living on the Web”. http://www.csc.com/aboutus/leadingedgeforum/knowledgelibrary/uploads/LEF_2007DigitalTrustVol5.pdf

56. So what are you telling me? That everything I thought I knew about security is wrong?

57. No. Not exactly .

58. I’m asserting two things…

59. 1) Many (many!) people in the ICT trade think that things like the limits of mathematics or cognitive science is irrelevant to their work.

60. They are wrong.

61. Fundamentally, engineering is about knowing and respecting the limitations of one’s materials.

62. ICT systems are built with software being one of the key materials.

63. And software is thoughtstuff.

64. For an engineer of thoughtstuff, the limitations of mathematics and cognitive science are the limitations of the material .

65. Russellian assumptions underlying “defense in depth” approaches to coping with risk need to be made explicit, because…

66. “ Defense in depth” not only will not achieve its stated goals…

67. “ Defense in depth” cannot achieve its stated goals.

68. http://en.wikipedia.org/wiki/Kurt_Gödel LOL!

69. 2) Because of that, we ought to study complex systems in Nature, learn how those systems cope with risk, uncertainty and so on, and apply those lessons to ICT.

70. We need to stop thinking in terms of “security” and start thinking in terms of “health”.

71. This is already true in your enterprise, if your systems landscape is not “small”

72. http://www.flickr.com/photos/rachels_secret/220269351/

73. It will become true, at the latest, once you begin to expand your landscape to include the Cloud.

74. So is everything we’ve got useless?

75. Of course not.

76. But we can’t go near the Cloud until we’ve fixed this?

77. Fortunately, that’s also not true.

78. You can use the Cloud now.

79. And that will be just as safe – as healthy – as you already are.

80. Like this…

82. You use existing, familiar tools, like VLANs, VPN tunnels, encrypted data (including storage), IPSec, and the faithful firewall.

83. You will likely run into the following problems:

84. 1) Static, manual configuration and management of your network and security infrastructure will probably not scale with demand.

85. There are tools on the market, available now and emerging, to meet this demand.

86. CohesiveFT VPN-Cubed, Cloudswitch, the next version of Cassatt, etc.

87. 2) Static, manual processes to provision and manage VMs will probably not scale to demand.

88. You will find yourself wanting to archive (versioned) VMs, ensure VMs have specific attributes, and otherwise maintain governance.

89. But you will also need a way to maintain the “self-service” factor, or risk torpedoing a significant part of the value proposition of the Cloud.

90. Again, there are tools available and emerging that can address some of these needs…

91. CohesiveFT ElsaticServer, rPath, Vmware, Enomalism, Elastra, 3Tera, many others

92. These tools have widely divergent solutions to these problems – choosing one involves many tradeoffs

93. You are likely to find that you want a coherent, unified platform to deal with both build- and run-time aspects.

94. And you are going to need to find a way to utilize multiple providers in parallel, if you want to be healthy.

95. RAIC – Redundant Array of Independent Cloud Providers

96. http://en.wikipedia.org/wiki/RAID

98. RAIC “solves” the problems of data portability and lock-in, whilst simultaneously increasing reliability, flexibility, and potentially, performance.

99. Diversity = health.

102. Hmm. What about the orchestrator? Single point of failure?

103. Yes.

104. So you have to ensure that it is designed to be healthy.

105. Available and emerging things worth considering in the context of the orchestrator include…

106. Eucalyptus: http://eucalyptus.cs.ucsb.edu/ UCI: http://code.google.com/p/unifiedcloud/ Ubuntu: https://wiki.edubuntu.org/UDSJaunty/Report/Server GridGain API: http://www.gridgain.com/product.html And also take a look at things like Puppet: http://reductivelabs.com/trac/puppet Chef: http://wiki.opscode.com/display/chef/Chef+Solo AMQP: http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol Hadoop: http://en.wikipedia.org/wiki/Hadoop … and so on.

107. That’s a lot to digest, but a picture of how to bring the Cloud inside the firewall emerges from it.

108. What about using the Cloud outside the firewall? What about, for example, collaborating with external partners in the Cloud?

109. Well, that’s where we all want to go.

110. But we can’t get there – safely and in good health – until certain hard problems are solved.

111. Problems like federated identity, for example.

112. Those kinds of problems cannot be solved via Russellian techniques.

113. And to the extent that current approaches embody Russellian assumptions, they cannot succeed.

114. So, no collaborative Cloud?

115. Not necessarily, but you will have to be aware of the context.

116. Think differently.

117. For example, concepts like “firewall” embody Russellian assumptions, and are only useful in the small.

118. Instead, consider concepts like quarantine , sterilization chambers and disinfection , for example.

119. Safe = healthy.

120. Join the conversation: http://groups.google.com/group/cloud-computing/ http://groups.google.com/group/cloudforum http://tech.groups.yahoo.com/group/cloudcomputing-tech/ … and please come talk to us, as well … http://twitter.com/mastermark http://twitter.com/gblnetwkr http://www.jroller.com/MasterMark/ Thanks!