Posts Tagged ‘Incomplete’
Incomplete Thought: On Horseshoes & Hand Grenades – Security In Enterprise Virt/Cloud Stacks
Last Updated on Saturday, 14 July 2012 04:45 Written by Celframe Security Team Monday, 29 October 2012 07:18
It’s not really *that* incomplete of a thought, but I figure I’d get it down on vPaper anyway…be forewarned, it’s massively over-simplified.
Over the last five years or so, I’ve spent my time working with enterprises who are building and deploying large scale (relative to an Enterprise’s requirements, that is) virtualized data centers and private cloud environments.
For the purpose of this discussion, I am referring to VMware-based deployments given the audience and solutions I will reference.
To this day, I’m often shocked with regard to how many of these organizations that seek to provide contextualized security for intra- and inter-VM traffic seem to position an either-or decision with respect to the use of physical or virtual security solutions.
For the sake of example, I’ll reference the architectural designs which were taken verbatim from my 2008 presentation “The Four Horsemen of the Virtualization Security Apocalypse.“
If you’ve seen/read the FHOTVA, you will recollect that there are many tradeoffs involved when considering the use of virtual security appliances and their integration with physical solutions. Notably, an all-virtual or all-physical approach will constrain you in one form or another from the perspective of efficacy, agility, and the impact architecturally, operationally, or economically.
The topic that has a bunch of hair on it is where I see many enterprises trending: obviating virtual solutions and using physical appliances only:
…the bit that’s missing in the picture is the external physical firewall connected to that physical switch. People are still, in this day and age, ONLY relying on horseshoeing all traffic between VMs (in the same or different VLANs) out of the physical cluster machine and to an external firewall.
Now, there are many physical firewalls that allow for virtualized contexts, zoning, etc., but that’s really dependent upon dumping trunked VLAN ports from the firewall/switches into the server and then “extending” virtual network contexts, policies, etc. upstream in an attempt to flatten the physical/virtual networks in order to force traffic through a physical firewall hop — sometimes at layer 2, sometimes at layer 3.
It’s important to realize that physical firewalls DO offer benefits over the virtual appliances in terms of functionality, performance, and some capabilities that depend on hardware acceleration, etc. but from an overall architectural positioning, they’re not sufficient, especially given the visibility and access to virtual networks that the physical firewalls often do not have if segregated.
Here’s a hint, physical-only firewall solutions alone will never scale with the agility required to service the virtualized workloads that they are designed to protect. Further, a physical-only solution won’t satisfy the needs to dynamically provision and orchestrate security as close to the workload as possible, when the workloads move the policies will generally break, and it will most certainly add latency and ultimately hamper network designs (both physical and virtual.)
Virtual security solutions — especially those which integrate with the virtualization/cloud stack (in VMware’s case, vCenter & vCloud Director) — offer the ability to do the following:
…which is to say that there exists the capability to utilize virtual solutions for “east-west” traffic and physical solutions for “north-south” traffic, regardless of whether these VMs are in the same or different VLAN boundaries or even across distributed virtual switches which exist across hypervisors on different physical cluster members.
For east-west traffic (and even north-south models depending upon network architecture) there’s no requirement to horseshoe traffic physically.
It’s probably important to mention that while the next slide is out-of-date from the perspective of the advancement of VMsafe APIs, there’s not only the ability to inject a slow-path (user mode) virtual appliance between vSwitches, but also utilize a set of APIs to instantiate security policies at the hypervisor layer via a fast path kernel module/filter set…this means greater performance and the ability to scale better across physical clusters and distributed virtual switching:
Interestingly, there also exists the capability to actually integrate policies and zoning from physical firewalls and have them “flow through” to the virtual appliances to provide “micro-perimeterization” within the virtual environment, preserving policy and topology.
There are at least three choices for hypervisor management-integrated solutions on the market for these solutions today:VMware vShield App,Cisco VSG+Nexus 1000v andJuniper vGW
Note that the solutions above can be thought of as “layer 2? solutions — it’s a poor way of describing them, but think “inter-VM” introspection for workloads in VLAN buckets. All three vendors above also have, or are bringing to market, complementary “layer 3? solutions that function as virtual “edge” devices and act as a multi-function “next-hop” gateway between groups of VMs/applications (nee vDC.) For the sake of brevity, I’m omitting those here (they are incredibly important, however.)
They (layer 2 solutions) are all reasonably mature and offer various performance, efficacy and feature set capabilities. There are also different methods for plumbing the solutions and steering traffic to them…and these have huge performance and scale implications.
It’s important to recognize that the lack of thinking about virtual solutions often seem to be based largely on ignorance of need and availability of solutions.
However, other reasons surface such as cost, operational concerns and compliance issues with security teams or assessors/auditors who don’t understand virtualized environments well enough.
From an engineering and architectural perspective, however, obviating them from design consideration is a disappointing concern.
Enterprises should consider a hybrid of the two models; virtual where you can, physical where you must.
If you’ve considered virtual solutions but chose not to deploy them, can you comment on why and share your thinking with us (even if it’s for the reasons above?)
Incomplete Thought: The Curious Case Of the Carnival Cloud
Last Updated on Monday, 12 March 2012 01:21 Written by Celframe Security Team Thursday, 23 August 2012 02:58
As a follow-on example to my blog titled The Curious Case of the MBO Cloud, in which I detailed the mad rush of companies to deploy something — anything — that looks like a “cloud” to achieve an artificial benchmark of cloudiness, I present you the oft-experienced “Carnival Cloud.”
What’s a Carnival Cloud?
Have you been to Disneyland? Perhaps a Six Flags theme park? Perhaps even Coney Island? If so, you’ve likely marveled at the engineering and physics associated with some of the rides. Seeing a train of interconnected people haulers hurtling around a steel (or wooden) substructure of vomit-inducing gravity abuse is a marvelous thing.
I saw a documentary on the construction of some of these modern wonders. Amazing. Well modeled, precision engineered, expertly designed and a remarkably good track record of safety. Yes, sometimes bad things happen, but rarely do you see a rollercoaster at a theme park decommissioned due to inherent design flaws.
I do however sometimes reflect on these rides and the notion that one willingly slaps down some money, straps in, gets rocketed around at 60+ mph pulling G’s rivaling that of some fighter aircraft and realize there’s really no Plan B should something go ass over tea kettles.
One simply has to trust in the quality of design, the skills of the engineering, the on-going maintenance efforts and the 16 year old who pushes the go-button after your crotch-squashing safety bar is slammed into one’s lap and morphs your unmentionables.
…keep your hands inside the ride at all times…
We trust that we’ll come out the other side and give no pause to the fact that the hopes for such are granted by the fact that these rides are often heavily automated, computer controlled and are instrumented to detect failure or flaw.
Now, have you been to a local fair or carnival?
Contrast your experience at Six Flags — often with the same level of risk — with a local carnival ride that’s unloaded from the back of a 1972 Chevy Stepsider, bolted together (and repeatedly unbolted) with some handtools and the sticky residue of lubricating oil and cotton candy.
I don’t know about you, but putting my life in the hands of carnie who does double duty as the bearded lady doesn’t inspire confidence, especially when the Tilt-o-whirl has the potential to demonstrate the unfortunate ramifications of cascading failure domains in physics that run well beyond the fact the some of these operators can’t count past the 4 missing fingers they have on their right hand.
This isn’t saying that carnivals aren’t fun. This isn’t implying that toothliness ain’t close to Godliness (especially when the afterlife is one missing bolt away.) This isn’t saying you shouldn’t go, thereby missing the nacho cheese-dipped pretzel logs and colon-clogging funnel cakes.
Nay, the point is to simply suggest that there’s a lot to be said for solid infrastructure — regardless of where it’s sourced — that’s performant, safe, operated and maintained in a ruthlessly diligent manner, instrumented well and is subject to constant rigor and inspection.
Relating that to cloud, your experience — depending upon your appetite for risk (and nacho cheese) — will dictate whether your E-ticket ride ends well or as a footnote on MSNBC.
Mmmm. Ableskivers and giant stuffed armadillos. Anyone got change for a $20?
Incomplete Thought: Cloud Capacity Clearinghouses & Marketplaces – A Security/Compliance/Privacy Minefield?
Last Updated on Monday, 12 March 2012 01:20 Written by Celframe Security Team Tuesday, 24 July 2012 03:46
With my focus on cloud security, I’m always fascinated when derivative business models arise that take the issues associated with “mainstream” cloud adoption and really bring issues of security, compliance and privacy into even sharper focus.
To wit, Enomaly recently launched SpotCloud – a Cloud Capacity Clearinghouse & Marketplace in which cloud providers can sell idle compute capacity and consumers may purchase said capacity based upon “…location, cost and quality.”
Got a VM-based workload? Want to run it cheaply for a short period of time?
…Have any security/compliance/privacy requirements?
To me, “quality” means something different that simply availability…it means service levels, security, privacy, transparency and visibility.
Whilst one can select the geographic location where your VM will run, as part of offering an “opaque inventory,” the identity of the cloud provider is not disclosed. This begs the question of how the suppliers are vetted and assessed for security, compliance and privacy. According to the SpotCloud FAQ, the answer is only a vague “We fully vet all market participants.”
There are two very interesting question/answer pairings on the SpotCloud FAQ that relate to security and service availability:
How do I secure my SpotCloud VM?
User access to VM should be disabled for increased security. The VM package is typically configured to automatically boot, self configure itself and phone home without the need for direct OS access. VM examples available.
Are there any SLA’s, support or guarantees?
No, to keep the costs as low as possible the service is offered without any SLA, direct support or guarantees. We may offer support in the future. Although we do have a phone and are more than happy to talk to you…
:: shudder ::
For now, I would assume that this means that if your workloads are at all mission critical, sensitive, subject to compliance requirements or traffic in any sort of sensitive data, this sort of exchange option may not be for you. I don’t have data on the use cases for the workloads being run using SpotCloud, but perhaps we’ll see Enomaly make this information more available as time goes on.
I would further assume that the criteria for provider selection might be expanded to include certification, compliance and security capabilities — all the more reason for these providers to consider something like CloudAudit which would enable them to provide supporting materials related to their assertions. (*wink*)
To be clear, from a marketplace perspective, I think this is a really nifty idea — sort of the cloud-based SETI-for-cost version of the Mechanical Turk. It takes the notion of “utility” and really makes one think of the options. I remember thinking the same thing when Zimory launched their marketplace in 2009.
I think ultimately this further amplifies the message that we need to build survivable systems, write secure code and continue to place an emphasis on the security of information deployed using cloud services. Duh-ja vu.
This sort of use case also begs the interesting set of questions as to what these monolithic apps are intended to provide — surely they transit in some sort of information — information that comes from somewhere? The oft-touted massively scaleable compute “front-end” overlay of public cloud often times means that the scale-out architectures leveraged to deliver service connect back to something else…
You likely see where this is going…
At any rate, I think these marketplace offerings will, for the foreseeable future, serve a specific type of consumer trafficking in specific types of information/service — it’s yet another vertical service offering that cloud can satisfy.
What do you think?