It's hard to avoid headlines that sensationalize the latest news about a security breach at company X that compromised some enormous amount of sensitive data at an estimated cost of (insert very large number). In fact, reports from the Ponemon Institute, Evalueserve/McAfee, the Information Risk Executive Council and Verizon/U.S. Secret Service/Politie, and others consolidate this type of information into easily digestible data. After reading these reports, you're left with the impression that enterprises are fighting a war and -- quite bluntly -- losing.
In a blog I wrote for InformationWeek, Cloud Security Frameworks: The Current State, I discussed the discipline known as systems engineering and management. The premise of this discipline is simple:
- The boundaries of any system are defined -- sometimes erroneously -- by the collective perspective of those participating in the effort.
- The more complex the effort, the greater the interactions and the more difficult the solution.
- If you try to focus on a single technology or business component of that system and exclude others, the success and effectiveness of the effort will likely suffer.
By applying this discipline to security investments, you conclude that for an enterprise to successfully address the many challenges of effective cloud security, it must align the entire ecosystem. An uncoordinated investment of individual pieces is a recipe for even more loss and simply extends the practice that's most responsible for the pathetic state of most enterprise security strategies today. With this in mind, let's examine Figure 1 and consider how security costs are calculated today.
As the fate of the RMS Titanic taught us, it's generally not the visible part of an iceberg that sinks you. Instead, it's the mass below the waterline you need to recognize, understand, and respect. The same is true of the total cost of security. In general, most costs associated with security lie beneath the waterline. And while this presents one series of challenges in a traditional framework, it presents a completely different scenario when you view this from a cloud community perspective.
In a typical enterprise, the security costs you can see coming are direct costs. These quantifiable expenses include staff, equipment, and software.
Still visible, yet a bit more difficult to quantify are indirect costs, which include training, lifecycle costs (e.g., equipment and software), and administration. In fact, security lifecycle costs are one of the greatest impediments to making intelligent investments. (We'll discuss this in depth in Part 2 of this blog post.)
Inefficiency costs are generally not easily identified and hard to quantify, even in a closed system (i.e., a typical, non-cloud-based framework). These can range from using and maintaining outdated hardware and software to overprotecting resources against non-existent threats. This subject is so important to cloud security, and to the effectiveness of your security strategy, that we'll discuss it in depth in Part 2. For now, let's focus on how your enterprise decides how to protect data today.
At the root level, data security is about two things: risk and trust.
Risk has two components, acceptance and management:
- Acceptance: Balancing threat against acceptable level of risk
- Management: Protecting data that really needs protecting
If you look at the model many enterprises use today, acceptance is more important than targeted data management. Why wouldn't it be? Security costs are a sunk expense and fall into a line-item budget bucket. Management efficiency costs are never really questioned, at least until a breach occurs. This condition, sadly, negates the necessity for an enterprise to actively manage the level of security, and associated costs, that is applied to specific data categories. The challenge is that in a mature cloud community, this will likely not be the case. Stratifying data into heavy versus lighter security needs means figuring out how much you pay for the service (perhaps as a factor of usage or volume).
Today, many enterprises apply security considerations uniformly, regardless of the true value of the data. This means costs are out of balance with the real threat. It goes back to the RMS Titanic and the iceberg. These costs will become much more visible in the cloud-and you'll need to scrutinize them more than you do today.
Trust has always been binary. There are no degrees of trust. I either trust you or I don't. What changes is the extent of trust.
If you approach trust (security) from a purely technical perspective, as a factor of remedies and infrastructure, you'll never establish a trusted relationship with your business. While this may be okay for a closed security system (i.e., one group driving security for an enterprise with no questions asked), it simply won't work when you expand into a mature cloud community. This inevitably leads to a question pertaining to whether trust can be bought if not earned, or once that trust is violated. While you may be able to buy trust in the short term, it's important to recognize that you will probably pay a higher price for it and that it may be prudent to establish trust through the broader ecosystem using more traditional approaches.
In Part 2 of this blog post, besides the topics we mentioned earlier, we'll discuss the apparent paradox between cloud security breaches and the investments that enterprises are willing to commit to win the security war.
I'm interested in your feedback on today's topic in general and, specifically, on how your enterprise funds security investment. To join the conversation, please contact me through Twitter.
As a principal enterprise architect, Bob Deutsche provides business and technical advisory services as well as thought leadership to mid- and senior-level executives in the Global 50 and public sector. He joined Intel in October 2004. With 30 years of experience in industry, Bob's varied background includes data center operations, software development and CIO positions. A retired Lt. Colonel in the U.S. Air Force, he holds a Master's of Science in Systems Management from the University of Southern California, Viterbi School of Engineering.
The above insights were provided to InformationWeek by Intel Corporation as part of a sponsored content program. The information and opinions expressed in this content are those of Intel Corporation and its partners and not InformationWeek or its parent, UBM TechWeb.