Posts Tagged ‘Whats’
What’s The Problem With Cloud Security? There’s Too Much Of It…
Last Updated on Monday, 12 March 2012 01:18 Written by Celframe Security Team Saturday, 9 June 2012 10:38
Here’s the biggest challenge I see in Cloud deployment as the topic of security inevitably occurs in conversation:
There’s too much of it.
Huh?
More specifically, much like my points regarding networking in highly-virtualized multi-tenant environments — it’s everywhere – we’ve got the same problem with security. Security is shot-gunned across the cloud landscape in a haphazard fashion…and the buck (pun intended) most definitely does not stop here.
The reality is that if you’re using IaaS, the lines of demarcation for the responsibility surrounding security may in one take seemed blurred but are in fact extremely well-delineated, and that’s the problem. I’ve seen quite a few validated design documents outlining how to deploy “secure multi-tentant virtualized environments.” One of them is 800 pages long.
Check out the diagram below.
I quickly mocked up an IaaS stack wherein you have the Cloud provider supplying, operating, managing and securing the underlying cloud hardware and software layers whilst the applications and information (contained within VM boundaries) are maintained by the consumer of these services. The list of controls isn’t complete, but it gives you a rough idea of what gets focused on. Do you see some interesting overlaps? How about gaps?
This is the issue; each one of those layers has security controls in it. There is lots of duplication and there is lots of opportunity for things to be obscured or simply not accounted for at each layer.
Each of these layers and functional solutions is generally managed by different groups of people. Each of them is generally managed by different methods and mechanisms. In the case of IaaS, none of the controls at the hardware and software layers generally intercommunicate and given the abstraction provided as part of the service offering, all those security functions are made invisible to the things running in the VMs.
A practical issue is that the FW, VPN, IPS and LB functions at the hardware layer are completely separate from the FW, VPN, IPS and LB functions at the software layer which are in turn completely separate from the FW, VPN, IPS and LB functions which might be built into the VM’s (or virtual appliances) which sit stop them.
The security in the hardware is isolated from the security in the software which is isolated from the security in the workload. You can, today, quite literally install the same capabilities up and down the stack without ever meeting in the middle.
That’s not only wasteful in terms of resources but incredibly prone to error in both construction, management and implementation (since at the core it’s all software, and software has defects.)
Keep in mind that at the provider level the majority of these security controls are focused on protecting the infrastructure, NOT the stuff atop it. By design, these systems are blind to the workloads running atop them (which are often encrypted both at rest and in transit.) In many cases this is why a provider may not be able to detect an “attack” beyond data such as flows/traffic.
To make things more interesting, in some cases the layer responsible for all that abstraction is now the most significant layer involved in securing the system as a whole and the fundamental security elements associated with the trust model we rely upon.
The hypervisor is an enormous liability; there’s no defense in depth when your primary security controls are provided by the (*ahem*) operating system provider. How does one provide a compensating control when visibility/transparency [detective] are limited by design and there’s no easy way to provide preventative controls aside from the hooks the thing you’re trying to secure grants access to?
“Trust me” ain’t an appropriate answer. We need better visibility and capabilities to robustly address this issue. Unfortunately, there’s no standard for security ecosystem interoperability from a management, provisioning, orchestration or monitoring perspective even within a single stack layer. There certainly isn’t across them.
In the case of Cloud providers who use commodity hardware with big, flat networks with little or no context for anything other than the flows/IP mappings running over them (thus the hardware layer is portrayed as truly commoditized,) how much better/worse do you think the overall security posture is of a consumer’s workload running atop this stack. No, that’s not a rhetorical question. I think the case could be argued either side of the line in the sand given the points I’ve made above.
This is the big suck. Cloud security suffers from the exact same siloed security telemetry problems as legacy operational models…except now it does it at scale. This is why I’ve always made the case that one can’t “secure the Cloud” — at least not holistically — given this lego brick problem. Everyone wants to make the claim that they’re technology is that which will be the first to solve this problem. It ain’t going to happen. Not with the IaaS (or even PaaS) model, it won’t.
However, there is a big opportunity to move forward here. How? I’ll give you a hint. It exists toward the left side of the diagram.
/Hoff
View the original article here
You Know What’s Dead? Security…
Last Updated on Sunday, 11 March 2012 09:43 Written by Celframe Security Team Tuesday, 3 April 2012 05:09
…well, it is if you listen to many of the folks who spend their time trawling about security conferences, writing blogs (like this one) or on podcasts, it is. I don’t share that opinion, however.
Lately there’s been a noisy upswing in the security echo chamber of people who suggest that given the visibility, scope, oft-quoted financial impact and reputational damage of recent breaches, that “security is losing.”
{…losing it’s mind, perhaps…}
What’s troubling about all this hen pecking is that with each complaint about the sorry state of the security “industry,” there’s rarely ever offered a useful solution that is appropriately adoptable within a reasonable timeframe, that satisfies a business condition, and result in an outcome that moves the needle to the “winning” side of the meter.
I was asked by Martin Mckeay (@mckeay) in a debate on Twitter, in which I framed the points above, if “…[I] don’t see all the recent breaches as evidence that we’re losing…that so many companies compromised as proof [that we're losing.]”
My answer was a succinct “no.”
What these breaches indicate is the constant innovation we see from attackers, the fact that companies are disclosing said breaches and the relative high-value targets admitting such. We’re also seeing the better organization of advanced adversaries whose tactics and goals aren’t always aligned with the profiles of “hackers” we see in the movies.
That means our solutions aren’t aligned to the problems we think we have nor the motivation and tactics of the attackers that these solutions are designed to prevent.
The dynamic tension between “us” and “them” is always cyclical in terms of the perception of who is “winning” versus “losing.” Always has been, always will be. Anyone who doesn’t recognize patterns in this industry is either:
NewIgnorantSelling you something…or all of the aboveMost importantly, it’s really, really important to recognize that the security “industry” is in business to accomplish one goal:
Make money.
It’s not a charity. It’s not a cause. It’s not a club. It’s a business.
The security industry — established behemoths and startups alike — are in the business of being in business. They may be staffed by passionate, idealistic and caring individuals, but those individuals enjoy paying their mortgages.
These companies also provide solutions that aren’t always ready from the perspective of market, economics, culture, adoptability, scope/impact of problem, etc. This is why I show the Security Hamster Sine Wave of Pain and why security, much like bell bottoms, comes back into vogue in cycles…generally when those items above converge.
Now, if you overlay what I just said with the velocity and variety of innovation without constraint that attackers play with and you have a clearer picture of why we are where we are.
Of course, no rant like this would be complete without the anecdotal handwaving bemoaning flawed trust models and technology, insecure applications and those pesky users…sigh.
The reality is that if we (as operators) are constrained to passive defense and are expected to score progress in terms of moving the defensive line forward versus holding ground, albeit with collateral damage, then yes…we’re losing.
If, rather, we assess our ability to influence outcomes such that the business can function at an acceptable level of risk, where “winning” and “losing” aren’t measured in emotional baggage or absolutes, then perhaps more often than not, we’d be winning instead of whining.
It’s all a matter of perspective, really.
I think staring at things other than one’s bellybutton can deliver some.
Try it. It won’t hurt. Promise.
/Hoff
View the original article here
Tags: security, Whats | Posted under Security | No Comments
What’s The Problem With Cloud Security? There’s Too Much Of It..
Last Updated on Tuesday, 6 March 2012 06:06 Written by Celframe Security Team Wednesday, 7 March 2012 05:06
Here’s the biggest challenge I see in Cloud deployment as the topic of security inevitably occurs in conversation:
There’s too much of it.
Huh?
More specifically, much like my points regarding networking in highly-virtualized multi-tenant environments — it’s everywhere – we’ve got the same problem with security. Security is shot-gunned across the cloud landscape in a haphazard fashion…and the buck (pun intended) most definitely does not stop here.
The reality is that if you’re using IaaS, the lines of demarcation for the responsibility surrounding security may in one take seemed blurred but are in fact extremely well-delineated, and that’s the problem. I’ve seen quite a few validated design documents outlining how to deploy “secure multi-tentant virtualized environments.” One of them is 800 pages long.
Check out the diagram below.
I quickly mocked up an IaaS stack wherein you have the Cloud provider supplying, operating, managing and securing the underlying cloud hardware and software layers whilst the applications and information (contained within VM boundaries) are maintained by the consumer of these services. The list of controls isn’t complete, but it gives you a rough idea of what gets focused on. Do you see some interesting overlaps? How about gaps?
This is the issue; each one of those layers has security controls in it. There is lots of duplication and there is lots of opportunity for things to be obscured or simply not accounted for at each layer.
Each of these layers and functional solutions is generally managed by different groups of people. Each of them is generally managed by different methods and mechanisms. In the case of IaaS, none of the controls at the hardware and software layers generally intercommunicate and given the abstraction provided as part of the service offering, all those security functions are made invisible to the things running in the VMs.
A practical issue is that the FW, VPN, IPS and LB functions at the hardware layer are completely separate from the FW, VPN, IPS and LB functions at the software layer which are in turn completely separate from the FW, VPN, IPS and LB functions which might be built into the VM’s (or virtual appliances) which sit stop them.
The security in the hardware is isolated from the security in the software which is isolated from the security in the workload. You can, today, quite literally install the same capabilities up and down the stack without ever meeting in the middle.
That’s not only wasteful in terms of resources but incredibly prone to error in both construction, management and implementation (since at the core it’s all software, and software has defects.)
Keep in mind that at the provider level the majority of these security controls are focused on protecting the infrastructure, NOT the stuff atop it. By design, these systems are blind to the workloads running atop them (which are often encrypted both at rest and in transit.) In many cases this is why a provider may not be able to detect an “attack” beyond data such as flows/traffic.
To make things more interesting, in some cases the layer responsible for all that abstraction is now the most significant layer involved in securing the system as a whole and the fundamental security elements associated with the trust model we rely upon.
The hypervisor is an enormous liability; there’s no defense in depth when your primary security controls are provided by the (*ahem*) operating system provider. How does one provide a compensating control when visibility/transparency [detective] are limited by design and there’s no easy way to provide preventative controls aside from the hooks the thing you’re trying to secure grants access to?
“Trust me” ain’t an appropriate answer. We need better visibility and capabilities to robustly address this issue. Unfortunately, there’s no standard for security ecosystem interoperability from a management, provisioning, orchestration or monitoring perspective even within a single stack layer. There certainly isn’t across them.
In the case of Cloud providers who use commodity hardware with big, flat networks with little or no context for anything other than the flows/IP mappings running over them (thus the hardware layer is portrayed as truly commoditized,) how much better/worse do you think the overall security posture is of a consumer’s workload running atop this stack. No, that’s not a rhetorical question. I think the case could be argued either side of the line in the sand given the points I’ve made above.
This is the big suck. Cloud security suffers from the exact same siloed security telemetry problems as legacy operational models…except now it does it at scale. This is why I’ve always made the case that one can’t “secure the Cloud” — at least not holistically — given this lego brick problem. Everyone wants to make the claim that they’re technology is that which will be the first to solve this problem. It ain’t going to happen. Not with the IaaS (or even PaaS) model, it won’t.
However, there is a big opportunity to move forward here. How? I’ll give you a hint. It exists toward the left side of the diagram.
Tags: Cloud, Problem, security, Theres, Whats | Posted under Celframe Security, Security, Web | No Comments