Infosec, Cloud & Money

I disdain talking about something that is hot at the moment, whether through research, adoption velocity or glamorous marketing. However after countless meetings listening to people trying to figure out the hype, I feel the urge to comment on a couple of ideas that are and will continue to be overlooked due to slick marketing materials, excellent websites, gifted sales people, impatience on the part of the customer to get a problem solved and ignorance in general by both parties. It is the challenged normal problem of person with problem seeking solution from vendor (or anyone perceived to be magical). In this case it is the individual and juxtaposed ideas of cloud computing, information security and money.

First let's talk about the premise that all customers need to find a fiscally responsible infrastructure solution.

Getting a Return on Your Leased/Rented Vendor Infrastructure

As for cloud computing ROI, there is no contest [Skilton]. The reality of 'renting' or 'leasing' virtualized elastically allocated space inside a vendor infrastructure receives no economic contest when compared to alternatively buying, administering and owning your own hardware infrastructure in /most/ cases.

We might be able to make a case for other economic solutions in the customer favor should we talk purely about commodity-based load-balanced farming, open-standards solutioning and lean supply-chain implementations; but when it comes to business and customers, it is true that we all get what we pay for (or deserve) in the end. And we have to know how to optimally use what we pay for as well. Then we have to discuss associative staffing, second and third-order operationally reliable infrastructure, processes, procedures, skills training, human resource management and the list goes on. There is no "buy an appliance" or “software package” and be done conversation. Like marriage and family, it comes with relatives. Owning your own infrastructure is cost and effort. Period.

Do the math. Leasing infrastructure, that comes with all the trimmings of back-up/recovery, redundancy and fail-over, 24x7 trained support staff and so on is, at face value, cheaper than owning it all yourself.

We can mathematically prove the ROI model for virtualized elastically allocated leased space in clean-room modeling. Yes, I said clean-room. We'll still need years of actuality to validate our initial hypothesis as should be expected. We cannot pretend to understand the math models of cloud without a more diverse array of customer types and attributes across a longer period of time. We'd like to. We cannot. Cloud isn’t just about the hardware. The hard infrastructure math is simple compared to the less quantifiable virtualized spaces and associative variable cost software stacks. We currently have no significant reason to disbelieve the math or the logic. However, time is the key. And we should expect that Marketing and Sales teams alike will no doubt try to compress that timeline by attempting to give us a premature sense of confidence.

Second to cloud ROI is information security. Or is it actually first? Nonetheless, sitting inside a verifiably certified physically and logically secure data-center 'somewhere else' is our second order of business. We’ll focus on the logical side only at this point for simplicity. However, one should note a complete risk management program includes both logical and physical security.

Understanding ROI for Proper Information Security

The math model for information security loss is still young in our experiential history [Berinato]. Many people I've encountered are still learning Moore’s law and its economic implications, how to perform company start-up valuations, begrudgingly accepting data suggesting defect prevention is cheaper than inspection and detection [Berinato], still don't want to believe Brooks' mythical man-month logic [Brooks], aka Brooks Law, still don’t know about, accept and/or understand project estimation implications of the McConnell documented cone of uncertainty factors (or even the predecessor NASA data) [McConnell], and romanticize having hot:hot fail-over while not wanting to spend a dime to implement it. Understanding leased elastic virtualized infrastructure math is something else to add to leadership knowledge "to-do lists". And the complexities of combinatorial testing against software versions in the stack against end-user OS browser combinations will not get easier, they will get harder now that everything will be virtualized. Exactly when is it “my” fault and when is it “your” fault there was a breach, fault and failure? Was it a stack issue? An interoperability issue within the stack, across stacks, across VMs? What? Prove it.

Vendor CFOs will want to look at an elastic virtualized machine (VM) solution as a multi-tenant building complex for rent. Straight math. Customer CFOs will still be forced to look at their slice of the pie as standard capital and operational expenditures located “off-site” with contracted staff and tight SLAs. Neither will consistently or effectively calculate preventive versus detective versus breach and response economics in terms of VM to VM breach on a single physical instance. Vendor CFOs will likely handle breach through customer-signed liability and fair-use statements while Customer CFOs will attempt to handle this scenario through vendor-signed SLAs and internal board-room whippings. I hope I’m wrong. I’d rather see purposed preventive measures on both sides to mitigate the need for executing the SLA and liability contracts. Some will simply adopt the logic that it’s easier to call a lawyer after a breach than it is to purposefully plan for, mitigate and prevent variable breach scenarios. Hard work is hard.

At least for now, based upon the news, tracking organizations and initial calculations by those that can, we know that one information security error will cost tens of thousands, millions or even billions across companies and industries due to miscreant mis-use of said data. We also know the second and third-order impacts will be personal, corporate, national and international, sometimes at the same time. Problems with leased VM space will impact legislation at the levels of countries. However understanding this math (cost of loss) requires more time and maturation to harden up the actual algorithmic risk:return:loss cost-model [DATALOSSdb] and many people simply do not know how to create and manage a fundamental information security risk diagrams for their operation [Harris], vendors and customers alike [DATALOSSdb].

Now in all fairness and anecdotally, it has taken us easily twenty years to evolve the software economic models of Boehm, IBM, NIST and others. Yet finding a CFO capable of including mature software economic theory in annual budgets is like looking for a needle in haystack. Either they understand it, or they simply log it in the Profit & Loss ledger as a “Research & Development” catch-all line-item with the ideas of preventive versus detective versus production fault and failure costs being completely lost in the shuffle. And finding an entrepreneurial CEO that cares past the lipstick might possibly be even harder. ‘Cloud’ marketing may well be ahead of useful reality so those catch-all line-items may get a lot of use in the coming years.

There are companies and technologists who have been using virtualization for years. It’s not new. However, it is my opinion that the masses, i.e. general consumers, do not fully understand what meal they are ordering when signing up for managing their domestic and/or multi-national business for cloud solutioning. It is additionally my opinion that the vendors do not fully understand the extent to which they will be liable in a “sue-your-neighbor-at-will” society for things yet to come. We’re all walking in smiling, side-by-side, whistling a happy tune. Politics includes the blame game. Cloud solutioning will amplify the “it’s not my fault” behavior and we’re going to see mess upon mess in the news and courts.

We have hard-math for hardware. We do not have hard-math for information security risk:return:loss scenarios. We have formulas [Harris]. Not enough information security people know them, let alone CxOs, managers and staff. We need more time, data and purposed education. So, how do you determine your own information security needs and in particular, sniff out experts from amateurs?

Determining Proper Information Security Measures

Snake-oil salespeople are all going to claim they have [ha.ackers] everything you need to be safe already in place. You hope that by going to a specialist they know more than you. You hope that because someone is a vendor in the particular field of your present interest that they are the expert. You hope. Ladies and Gentlemen, in the world of a new business markets, vendors will come out of the walls and every single one of them will be an expert. We’re going to be swimming in ‘cloud experts’ for quite some time just like we’ve been swimming in ‘Agile experts’, ‘Rational experts’, ‘SDLC experts’, ‘Web Programming experts’, ‘Start-up experts’, ‘Requirements gathering experts’, ‘financial forecast experts’ and ‘national security experts’ for decades. Strap in, there’s a new roller coaster in town.

Make vendors prove it.

It is far easier to prove a vendor has physical solutions in place than logical ones. They can show you glossy pictures of arbitrary hardware stacks, network topologies, data-centers, people in suits and their associative CVs, armed guards and Trolls that guard the bridge over the moat that’s home to a sea monster who eats bad people, but they can’t show you pictures of information security measures they have in place to protect you, your company and your data. They can tell you, but unless you are an information security junkie and past tech-head, what they say may sound impressive to you, but actually be meaningless blather. So we have to rely upon third-party consultants, certification, audit and test organizations to validate an organization's implementations against current industry standards, trends and bodies of knowledge. It is non-negotiable for those with the presence of mind to think with greater depth and breadth than the pretty hardware stack in a locked cabinet and cage with blinky lights.

Ladies and Gentlemen, you want to know about the vendor company’s processes, procedures, certifications, audits and re-certifications just to start the conversation. We’re not even discussing the main course of standard operating procedures for production support, monitoring, response time and resolution, penetration tests, and social things like asking for a list of other customers the vendor may already have that forced high-information security standards of implementation and so on. For example, if a vendor has a Federal Government customer, we know they had to jump a certain height already. Conversely, if a vendor has a local mom and pop shop as a customer, the bar is likely low. Whether it is too low for you is up to you to determine. And whether you’re willing to fund your vendor’s education and infrastructure maturation journey is a business risk decision on you’re part. It is not the nature of vendors to walk away from gigs because they aren’t qualified.
  1. Ask a vendor if they have information security experts on staff. If yes, ask to see their CV. Ask about their information security qualifications. You want to see information security on-staff having multiple years of technical experience and with one or more of the following certifications such as CISSP, CISA, GIAC, etc. Ask to see their certification numbers and where it can be verified online or at the certifying organization in question.

  2. Ask a vendor where their data-centers are located (address), what physical security procedures are in place managing physical access, and what information security certifications exist for said structures. You want to see certifications and validated third-party compliance statements against things like SAS70, ISO, IEC, MIL-SPEC, etc. Ask to see the actual certification papers. Ask to see the results of the last audit(s) and proof that any deficits have been addressed. Physically visit the data-center when possible.

  3. Ask a vendor what information security certifications their company has, when they were received, when the last audit occurred and when the next audit is to occur. Ask to see the actual certification papers. Ask to see the results of the last audit(s) and proof that any deficits have been addressed.

  4. Ask a vendor if and when they’ve hired a third party organization to perform penetration tests against their infrastructure AND any software applications they will be providing for you. Ask to see the results of the test and for proof that any deficits found were addressed. If they are secure as suggested, a little penetration test shouldn’t scare them, but rather embolden them.

Highly regulated industries require on-going evidence of audit/test, deficit and fix; so can you. If the vendor wants to play in your industry, make them pay for their own certs, tests and accolades. Everything I’ve said in this article is independently verifiable on your own. Don’t take a vendor’s word for it. Do your own research or hire someone to represent you in this endeavor. The cost of doing it wrong will be more expensive than hiring someone to do it right on your behalf. Think about that.

As for cloud, return on investment and information security risks and liabilities, only you, the customer, can determine your risk and funding tolerances. Only you, the customer, can sift through the riff raff to determine a proper vendor associatively. After you understand your risk, you're better equipped to determine your solution possibilities by looking at multiple vendors. If you need help assessing your risk and funding tolerance, ask a third-party technical security consultant, not a cloud vendor. If you don't know your risks but believe you are ‘smart’ or have ‘smart’ people on staff, good luck.

Preventive, detective and corrective information and physical security measures are never ‘done’, they are only ‘done at this moment’. The ‘next moment’ may define you.


Atwood, Jeff. "The Mysterious Cone of Uncertainty". June 28 2006

Berinato, Scott. CIO. “Software Security: The Bug Stops Here”. May 15, 2003.

Boehm, Barry W. Software Engineering Economics. Prentice Hall. 1981.

Brooks, Frederick P. Mythical Man-Month. Addison-Wesley Professional. 1995.

Construx. "The Cone of Uncertainty".

DATALOSSdb. Open Security Foundation.

ha.ackers. "The Effect of Snakeoil Security".

Harris, Shon. All In One CISSP Exam Guide. McGraw-Hill. 2010. Fifth Edition.

Jackson, Kevin. "Open Group Publishes Guidelines on Cloud Computing ROI". May 2, 2010.

McConnell, Steve. "Software Estimation: Demystifying the Black Art". Microsoft Press. 2006.

Skilton, Mark. "How to Build ROI from Cloud Computing". December 9, 2010.

Thibodeau, Patrick. ComputerWorld. "Study: Buggy software costs users, vendors nearly $60B annually". June 25, 2002. 12:00 PM ET.