Cloud Security Frameworks: Big Data, Architecture and Colin Chapman

Please note:  A version of this blog appeared on in the Cloud Section as an Intel sponsored post

I have a passion for anything with wheels, wings and more recently, float planes. You might remember that if you’ve read any of the blog posts I wrote on enterprise cloud (or the white paper based on them). Now I’m going to use this passion to make a point about cloud security.

Who is Colin Chapman? And what can we Learn from Him?

Anthony Colin Chapman  was a design engineer, inventor, and founder of Lotus Cars , a British manufacturer of sports and racing cars known for their exceptional handling and light weight. In a nutshell, Chapman’s design philosophy is “simplify, then add lightness.” In practical terms, this approach ensured his cars were fast— not only on the straights, but particularly in the corners. In fact, between 1962 and 1978, Team Lotus won seven Formula One Constructor titles, six Driver’s Championships, and the Indianapolis 500. Based on results, it seems Colin may have been onto something.

So what exactly does Colin Chapman’s philosophy on lightness and speed have to do with cloud security, big data, and IT architecture? To find out, let’s focus on your current state data architecture strategy.

Current State Data Architecture and Security

Let’s pick a data category that is (according to a white paper  from the Ponemon Institute) a consistent source of security concern to enterprises worldwide: customer data.

If I were to audit your enterprise data architecture, how many instances of customers’ data records would I find? One? Three? Six ? M aybe more? Would you be surprised if I told you that as an IT auditor (before I worked for Intel), I would routinely find at least six distinct data records on the same customer in a typical U.S.-based company?

If you continued auditing these islands of customer data, comparing them at the record level, what do you think you might find? Would the information be consistent in content, use, and ownership?  Chances of that happening are not very likely.

As an auditor, I generally found approximately 75 percent parity among these records. What about the status of the other 25 or so percent of the information? Would it reflect the nuances of whatever department owned and maintained the record? What would the value of these nuances be to a competitor, or to a bad guy who hacked the record? What would you suspect Colin Chapman might say about the impact on enterprise performance of the (debatably) needless weight of all this duplicate data?

With all this in mind, let’s move the discussion to big data and the cloud.

First, it’s important to frame big data as simply as possible (understanding that it means many things to many people). Basically, big data is about harnessing the power of analytics to mine useful business intelligence (BI) out of massive amounts of ostensibly non-related information. The amount of information is so massive that a typical enterprise data center doesn’t have the capacity to conduct this analysis inside its firewall.

If this definition is fairly accurate, then information about your customers would likely be of value to your BI effort.

Now the question becomes exactly which of the theoretical six customer data records would you use in the cloud as part of your big data strategy? Would you default to using the one record that reflects the greatest percentage of commonality among the six? Or would you simply continue to utilize all the records in the cloud?

Most companies— due to history, effort, potential organizational ownership confrontations, and related difficulties— would take the easiest route and place all six customer records in the cloud. (If your company has done something else, please let me know. I’d love to be proven wrong.)

Structural Security Implications

In Sun-Tzu’s The Art of War[ 1], the author speaks of five types of incendiary attacks. The first is to incinerate men, the second is to incinerate provisions, the third is to incinerate supply trains, the fourth is to incinerate armories, and the fifth is to incinerate formations. Let’s explore this premise using customer records.

Consider that each customer record represents a standalone formation of data provisions, all being exchanged via very long, and very exposed, supply lines. Where one record has its related security concerns, six records, containing fundamentally the same data (at least 75 percent), have more.

I suggested in an earlier blog  that bad guys seem to be much more adept at taking advantage of structural security weaknesses than we are at defending them. So not only does the extra weight of these records impact performance (a la Colin Chapman), it also gives the bad guys a target-rich environment that’s easier to breach. Since continuing to move toward the cloud and big data is inevitable, what actions do we need to start— or should we already have in place— to prepare for what I call future state security?

In my next blog post, I’ll begin to define what a future state security framework (and its funding) should look like and offer suggestions on how roles and responsibilities must evolve as the boundaries of your organization expand.

Please join me as I explore the topic of cloud security across upcoming blogs.  For now, and reserving the right to add or modify these topics as we move forward, here are the areas I'll address in the coming months:

1.  Current State Security

2.  Security as a Factor of Cost

3.  Business Issues Surrounding Security

4.  Evaluating New-World Security Model Investments

5.  Security, Data Architecture and Big Data

6.  Defense in Depth

As always, I’m interested in your feedback to learn how your organization is selecting data to include in your big data strategy. I’d also like to know if you’re planning on managing your data architecture differently than you did when it only existed inside your firewall. To join the conversation, please contact me through Twitter.

[1] Sun-Tzu, The Art of War, Translated by Ralph D. Sawyer, Fall River Press, 1994, p. 227.