Rational Survivability

…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:

1. New
2. Ignorant
3. Selling you something
4. …or all of the above

Most 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

Related articles

• Bringing Sexy back (to Security): Mike’s RSAC 2012 Wrap-up (securosis.com)
• Hacking breach made us stronger says RSA (go.theregister.com)
• Building/Bolting Security In/On – A Pox On the Audit Paradox! (rationalsurvivability.com)
• PSA: Paula Deen, Sausage Pancake Egg Sandwiches & Security… (rationalsurvivability.com)

I spent yesterday at the PacketPushers/TechFieldDay OpenFlow Symposium. The event provided a good overview of what OpenFlow [currently] means, how it fits into the overall context of software-defined networking (SDN) and where it might go from here.

I’d suggest reading Ethan Banks’ (@ecbanks) overview here.

Many of us left the event, however, still wondering about what the “killer app” for OpenFlow might be.

Chatting with Ivan Pepelnjak (@ioshints) and Derrick Winkworth (@CloudToad,) I reiterated that selfishly, I’m still thrilled about the potential that OpenFlow and SDN can bring to security.  This was a topic only briefly skirted during the symposium as the ACL-like capabilities of OpenFlow were discussed, but there’s so much more here.

I wrote about this back in May (OpenFlow & SDN – Looking forward to SDNS: Software Defined Network Security):

… “security” needs to be as programmatic/programmable, agile, scaleable and flexible as the workloads (and stacks) it is designed to protect. “Security” in this context extends well beyond the network, but the network provides such a convenient way of defining templated containers against which we can construct and enforce policies across a wide variety of deployment and delivery models.

So as I watch OpenFlow (and Software Defined Networking) mature, I’m really, really excited to recognize the potential for a slew of innovative ways we can leverage and extend this approach to networking [monitoring and enforcement] in order to achieve greater visibility, scale, agility, performance, efficacy and reduced costs associated with security.  The more programmatic and instrumented the network becomes, the more capable our security options will become also.

I had to chuckle at a serendipitous tweet from a former Cisco co-worker (Stefan Avgoustakis, @savgoust) because it’s really quite apropos for this topic:

…I think he’s oddly right!

Frankly, if you look at what OpenFlow and SDN (and network programmability in general) gives an operator — the visibility and effective graph of connectivity as well as the multiple-tupule flow action capabilities, there are numerous opportunities to leverage the separation of control/data plane across both virtual and physical networks to provide better security capabilities in response to threats and at a pace/scale/radius commensurate with said threat.

To be able to leverage telemetry and flow tables in the controllers “centrally” and then “dispatch” the necessary security response on an as-needed basis to the network location ONLY that needs it, really does start to sound a lot like the old “immune system” analogy that SDN (self defending networks) promised.

The ability to distribute security capabilities more intelligently as a service layer which can be effected when needed — without the heavy shotgunned footprint of physical in-line devices or the sprawl of virtualized appliances — is truly attractive.  Automation for detection and ultimately prevention is FTW.

Bundling the capabilities delivered via programmatic interfaces and coupling that with ways of integrating the “network” and “applications” (of which security is one) produces some really neat opportunities.

Now, this isn’t just a classical “data center core” opportunity, either. How about the WAN/Edge?  Campus, branch…? Anywhere you have the need to deliver security as a service.

For non-security examples, check out Dave Ward’s (my Juniper colleague) presentation “Programmable Networks are SFW” where he details interesting use cases such as “service engineered paths,” “service appliance pooling,” “service specific topology,” “content request routing,” and “bandwidth calendaring” for example.

…think of the security ramifications and opportunities linked to those capabilities!

I’ve mocked up a couple of very interesting security prototypes using OpenFlow and some open source security components; from IDP to Anti-malware and the potential is exciting because OpenFlow — in conjunction with other protocols and solutions in the security ecosystem — could provide some of the missing glue necessary to deliver a constant,  but abstracted security command/control (nee API-like capability) across heterogenous infrastructure.

NOTE: I’m not suggesting that OpenFlow itself provide these security capabilities, but rather enable security solutions to take advantage of the control/data plane separation to provide for more agile and effective security.

If the potential exists for OpenFlow to effectively allow choice of packet forwarding engines and network virtualization across the spectrum of supporting vendors’ switches, it occurs to me that we could utilize it for firewalls, intrusion detection/prevention engines, WAFs, NAC, etc.

Thoughts?

Related articles

• What’s OpenFlow’s killer app? (infoworld.com)
• OpenFlow and SDN: Networking’s future? (networkworld.com)
• Can OpenFlow Unlock More of Virtualization’s Potential? (informationweek.com)
• OpenFlow Tutorial: Next-Gen Networking Has Much To Prove (informationweek.com)
• Network Virtualization is like a big virtual chassis (bradhedlund.com)
• A Contentious Question: The Value Proposition & Target Market Of Virtual Networking Solutions? (rationalsurvivability.com)
• VMware’s vShield – Why It’s Such A Pain In the Security Ecosystem’s *aaS… (rationalsurvivability.com)
• (Physical, Virtualized and Cloud) Security Automation – An API Example (rationalsurvivability.com)
• SecurityAutomata: A Reference For Security Automation… (rationalsurvivability.com)

I’ve become…comfortably numb…

Whilst attending VMworld 2011 last week, I attended a number of VMware presentations, hands-on labs and engaged in quite a few discussions related to VMware’s vShield and overall security strategy.

I spent a ton of time discussing vShield with customers — some who love it, some who don’t — and thought long and hard about writing this blog.  I also spent some time on SiliconAngle’s The Cube discussing such, here.

I have dedicated quite a lot of time discussing the benefits of VMware’s security initiatives, so it’s important that you understand that I’m not trying to be overtly negative, nor am I simply pointing fingers as an uneducated, uninterested or uninvolved security blogger intent on poking the bear.  I live this stuff…every day, and like many, it’s starting to become messy. (Ed: I’ve highlighted this because many seem to have missed this point. See here for example.)

It’s fair to say that I have enjoyed “up-to-the-neck” status with VMware’s various security adventures since the first marketing inception almost 4 years ago with the introduction of the VMsafe APIs.  I’ve implemented products and helped deliver some of the ecosystem’s security offerings.  My previous job at Cisco was to provide the engineering interface between the two companies, specifically around the existing and next generation security offerings, and I now enjoy a role at Juniper which also includes this featured partnership.

I’m also personal friends with many of the folks at VMware on the product and engineering teams, so I like to think I have some perspective.  Maybe it’s skewed, but I don’t think so.

There are lots of things I cannot and will not say out of respect for obvious reasons pertaining to privileged communications and NDAs, but there are general issues that need to be aired.

Geez, enough with the CYA…get on with it then…

As I stated on The Cube interview, I totally understand VMware’s need to stand-alone and provide security capacities atop their platform; they simply cannot expect to move forward and be successful if they are to depend solely on synchronizing the roadmaps of dozens of security companies with theirs.

However, the continued fumbles and mis-management of the security ecosystem and their partnerships as well as the continued competitive nature of their evolving security suite makes this difficult.  Listening to VMware espouse that they are in the business of “security ecosystem enablement” when there are so few actually successful ecosystem partners involved beyond antimalware is disingenuous…or at best, a hopeful prediction of some future state.

Here’s something I wrote on the topic back in 2009: The Cart Before the Virtual Horse: VMware’s vShield/Zones vs. VMsafe APIs that I think illustrates some of the issues related to the perceived “strategy by bumping around in the dark.”

A big point of confusion is that vShield simultaneously describes both an ecosystem program and a set of products that is actually more than just anti-malware capabilities which is where the bulk of integration today is placed.

Analysts and journalists continue to miss the fact that “vShield” is actually made up of 4 components (not counting the VMsafe APIs):

• vShield Edge
• vShield App
• vShield Endpoint
• vShield Manager

What most people often mean when they refer to “vShield” are the last two components, completely missing the point that the first two products — which are now monetized and marketed/sold as core products for vSphere and vCloud Director — basically make it very difficult for the ecosystem to partner effectively since it’s becoming more difficult to exchange vShield solutions for someone else’s.

An important reason for this is that VMware’s sales force is incentivized (and compensated) on selling VMware security products, not the ecosystem’s — unless of course it is in the way of a big deal that only a partnership can overcome.  This is the interesting juxtaposition of VMware’s “good enough” versus incumbent security vendors “best-of-breed” product positioning.

VMware is not a security or networking company and ignoring the fact that big companies with decades of security and networking products are not simply going to fade away is silly.  This is true of networking as it is security (see software-defined networking as an example.)

Technically, vShield Edge is becoming more and more a critical piece of the overall architecture for VMware’s products — it acts as the perimeter demarcation and multi-tenant boundary in their Cloud offerings and continues to become the technology integration point for acquisitions as well as networking elements such as VXLAN.

As a third party tries to “integrate” a product which is functionally competitive with vShield Edge, the problems start to become much more visible and the partnerships more and more clumsy, especially in the eyes of the most important party privy to this scenario: the customer.

Jon Oltsik wrote a story recently in which he described the state of VMware’s security efforts: “vShield, Cloud Computing, and the Security Industry”

So why aren’t more security vendors jumping on the bandwagon? Many of them look at vShield as a potentially competitive security product, not just a set of APIs.

In a recent Network World interview, Allwyn Sequeira, VMware’s chief technology officer of security and vice president of security and network solutions, admitted that the vShield program in many respects “does represent a challenge to the status quo” … (and) vShield does provide its own security services (firewall, application layer controls, etc.)

Why aren’t more vendors on-board? It’s because this positioning of VMware’s own security products which enjoy privileged and unobstructed access to the platform that ISV’s in the ecosystem do not have.  You can’t move beyond the status quo when there’s not a clear plan for doing so and the past and present are littered with the wreckage of prior attempts.

VMware has its own agenda: tightly integrate security services into vSphere and vCloud to continue to advance these platforms. Nevertheless, VMware’s role in virtualization/cloud and its massive market share can’t be ignored. So here’s a compromise I propose:

1. Security vendors should become active VMware/vShield partners, integrate their security solutions, and work with VMware to continue to bolster cloud security. Since there is plenty of non-VMware business out there, the best heterogeneous platforms will likely win.
2. VMware must make clear distinctions among APIs, platform planning, and its own security products. For example, if a large VMware shop wants to implement vShield for virtual security services but has already decided on Symantec (Vontu) or McAfee DLP, it should have the option for interoperability with no penalties (i.e., loss of functionality, pricing/support premiums, etc.).

Item #1 Sounds easy enough, right? Except it’s not.  If the way in which the architecture is designed effectively locks out the ecosystem from equal access to the platform except perhaps for a privileged few, “integrating” security solutions in a manner that makes those solutions competitive and not platform-specific is a tall order.  It also limits innovation in the marketplace.

Look how few startups still exist who orbit VMware as a platform.  You can count them on less fingers that exist on a single hand.  As an interesting side-note, Catbird — a company who used to produce their own security enforcement capabilities along with their strong management and compliance suite — has OEM’d VMware’s vShield App product instead of bothering to compete with it.

Now, item #2 above is right on the money.  That’s exactly what should happen; the customer should match his/her requirements against the available options, balance the performance, efficacy, functionality and costs and ultimately be free to choose.  However, as they say in Maine…”you can’t get there from here…” at least not unless item #1 gets solved.

In a complimentary piece to Jon’s, Ellen Messmer writes in “VMware strives to expand security partner ecosystem“:

Along with technical issues, there are political implications to the vShield approach for security vendors with a large installed base of customers as the vShield program asks for considerable investment in time and money to develop what are new types of security products under VMware’s oversight, plus sharing of threat-detection information with vShield Manager in a middleware approach.

…and…

The pressure to make vShield and its APIs a success is on VMware in some respects because VMware’s earlier security API , the VMsafe APIs, weren’t that successful. Sequiera candidly acknowledges that, saying, “we got the APIs wrong the first time,” adding that “the major security vendors have found it hard to integrate with VMsafe.”

Once bitten, twice shy…

So where’s the confidence that guarantees it will be easier this time? Basically, besides anti-malware functionality provided by integration with vShield endpoint, there’s not really a well-defined ecosystem-wide option for integration beyond that with VMware now.  Even VMware’s own roadmaps for integration are confusing.  In the case of vCloud Director, while vShield Edge is available as a bundled (and critical) component, vShield App is not!

Also, forcing integration with security products now to directly integrate with vShield Manager makes for even more challenges.

There are a handful of security products besides anti-malware in the market based on the VMsafe APIs, which are expected to be phased out eventually. VMware is reluctant to pin down an exact date, though some vendors anticipate end of next year.

That’s rather disturbing news for those companies who have invested in the roadmap and certification that VMware has put forth, isn’t it?  I can name at least one such company for whom this is a concern. 🙁

Because VMware has so far reserved the role of software-based firewalls and data-loss prevention under vShield to its own products, that has also contributed to unease among security vendors. But Sequiera says VMware is in discussions with Cisco on a firewall role in vShield.   And there could be many other changes that could perk vendor interest. VMware insists its vShield APIs are open but in the early days of vShield has taken the approach of working very closely with a few selected vendors.

Firstly, that’s not entirely accurate regarding firewall options. Cisco and Juniper both have VMware-specific “firewalls” on the market for some time; albeit they use different delivery vehicles.  Cisco uses the tightly co-engineered effort with the Nexus 1000v to provide access to their VSG offering and Juniper uses the VMsafe APIs for the vGW (nee’ Altor) firewall.  The issue is now one of VMware’s architecture for integrating moving forward.

Cisco has announced their forthcoming vASA (virtual ASA) product which will work with the existing Cisco VSG atop the Nexus 1000v, but this isn’t something that is “open” to the ecosystem as a whole, either.  To suggest that the existing APIs are “open” is inaccurate and without an API-based capability available to anyone who has the wherewithal to participate, we’ll see more native “integration” in private deals the likes of which we’re already witnessing with the inclusion of RSA’s DLP functionality in vShield/vSphere 5.

Not being able to replace vShield Edge with an ecosystem partner’s “edge” solution is really a problem.

In general, the potential for building a new generation of security products specifically designed for VMware’s virtualization software may be just beginning…

Well, it’s a pretty important step and I’d say that “beginning” still isn’t completely realized!

It’s important to note that these same vendors who have been patiently navigating VMware’s constant changes are also looking to emerging competitive platforms to hedge their bets. Many have already been burned by their experience thus far and see competitive platform offerings from vendors who do not compete with their own security solutions as much more attractive, regardless of how much marketshare they currently enjoy.  This includes community and open source initiatives.

Given their druthers, with a stable, open and well-rounded program, those in the security ecosystem would love to continue to produce top-notch solutions for their customers on what is today the dominant enterprise virtualization and cloud platform, but it’s getting more frustrating and difficult to do so.

It’s even worse at the service provider level where the architectural implications make the enterprise use cases described above look like cake.

It doesn’t have to be this way, however.

Jon finished up his piece by describing how the VMware/ecosystem partnership ought to work in a truly cooperative manner:

This seems like a worthwhile “win-win,” as that old tired business cliche goes. Heck, customers would win too as they already have non-VMware security tools in place. VMware will still sell loads of vShield product and the security industry becomes an active champion instead of a suspicious player in another idiotic industry concept, “coopitition.” The sooner that VMware and the security industry pass the peace pipe around, the better for everyone.

The only thing I disagree with is how this seems to paint the security industry as the obstructionist in this arms race.  It’s more than a peace pipe that’s needed.

Puff, puff, pass…it’s time for more than blowing smoke.

/Hoff

Related articles

• VMware’s (New) vShield: The (Almost) Bottom Line (rationalsurvivability.com)
• VMware strives to expand security partner ecosystem (infoworld.com)
• VMware preparing data loss prevention features for vShield (infoworld.com)
• Highlights from VMworld 2011 (datacenterknowledge.com)
• Clouds, WAFs, Messaging Buses and API Security… (rationalsurvivability.com)
• AWS’ New Networking Capabilities – Sucking Less  (rationalsurvivability.com)
• Sourcefire Enables Application Control Within Virtual Environments (it-sideways.com)
• Using The Cloud To Manage The Cloud (informationweek.com)
• Virtualizing Your Appliance Is Not Cloud Security (securecloudreview.com)
• OpenFlow & SDN – Looking forward to SDNS: Software Defined Network Security(rationalsurvivability.com)

The SecurityAutomata Project is themed toward enabling consumers, service and technology solution providers to collectively share knowledge on how to automate and focus on the programmability of “security” across physical, virtual and cloud environments.

It’s a bit of an experiment, really. I want to enable better visibility into the state-of-the-art (as it were) of security automation by providing a neutral ground to discuss and demonstrate how security can be automated in physical, virtual and cloud computing environments.

There are many solutions available today but it’s often difficult to grasp how the approaches differ from one another and what sort of capabilities must exist to get them to work.

Please help us organize and contribute content to the SecurityAutomata Wiki here.

/Hoff

Related articles

• (Physical, Virtualized and Cloud) Security Automation – An API Example (rationalsurvivability.com)
• OpenFlow & SDN – Looking forward to SDNS: Software Defined Network Security (rationalsurvivability.com)
• Clouds, WAFs, Messaging Buses and API Security… (rationalsurvivability.com)
• Cloud & Virtualization Stacks: Users Fear Lock-In, Ecosystem Fears Lock-Out… (rationalsurvivability.com)
• Security: “There’s No Discipline In Our Discipline” (rationalsurvivability.com)

OK, that’s not really a question, it’s a bit of a giddy, self-referential, fanboi-ish anouncement.

In the April 2011 “How It Works” issue of Popular Science, a magazine I’ve loved since I was a kid, Marie Pacella wrote a great story on security and cloud computing.

I was thrilled to be included in several sections and for once I’m not bashful about tooting my own horn — this is so cool to me personally!

The sections that went through editing got cut down quite bit, but originally the drafts included some heavier details on the mechanics and some more meaty sections on technical elements (and theoretical stuff,) but I think Marie and the editors did a great job.  The graphics were awesome, also.

At any rate, if you subscribe to the magazine or better yet have the iPad application (which is awesome,) you can check it out.

Don’t have an iPad or the magazine?  Read the story here

Image via Wikipedia

CA recently sponsored the second in a series of Ponemon Institute cloud computing security surveys.

The first, released in May, 2010 was focused on responses from practitioners: “Security of Cloud Computing Users – A Study of Practitioners in the US & Europe”

The latest titled “Security of Cloud Computing Providers Study (pdf),” released this week, examines “cloud computing providers'” perspectives on the same.  You can find the intro here.

While the study breaks down the  survey in detail in Appendix 1, I would kill to see the respondent list so I could use the responses from some of these “cloud providers” to quickly make assessments of my short list of those to not engage with.

I suppose it’s not hard to believe that security is not a primary concern, but given all the hype surrounding claims of “cloud is more secure than the enterprise,” it’s rather shocking to think that this sort of behavior is reflective of cloud providers.

Let’s see why.

This survey qualifies those surveyed as such:

We surveyed 103 cloud service providers in the US and 24 in six European countries for a total of 127 separate providers. Respondents from cloud provider organizations say SaaS (55 percent) is the most frequently offered cloud service, followed by IaaS (34 percent) and PaaS (11 percent). Sixty-five percent of cloud providers in this study deploy their IT resources in the public cloud environment, 18 percent deploy in the private cloud and 18 percent are hybrid.

…and offers these most “salient” findings:

• The majority of cloud computing providers surveyed do not believe their organization views the security of their cloud services as a competitive advantage. Further, they do not consider cloud computing security as one of their most important responsibilities and do not believe their products or services substantially protect and secure the confidential or sensitive information of their customers.
  –
• The majority of cloud providers believe it is their customer’s responsibility to secure the cloud and not their responsibility. They also say their systems and applications are not always  evaluated for security threats prior to deployment to customers.
  –
• Buyer beware – on average providers of cloud computing technologies allocate 10 percent or less of their operational resources to security and most do not have confidence that  customers’ security requirements are being met.
  –
• Cloud providers in our study say the primary reasons why customers purchase cloud  resources are lower cost and faster deployment of applications. In contrast, improved security  or compliance with regulations is viewed as an unlikely reason for choosing cloud services. The majority of cloud providers in our study admit they do not have dedicated security  personnel to oversee the security of cloud applications, infrastructure or platforms.
  –
  
• Providers of private cloud resources appear to attach more importance and have a higher  level of confidence in their organization’s ability to meet security objectives than providers of  public and hybrid cloud solutions.
  _
• While security as a “true” service from the cloud is rarely offered to customers today, about  one-third of the cloud providers in our study are considering such solutions as a new source  of revenue sometime in the next two years.

Ultimately, CA summarized the findings as such:

“The focus on reduced cost and faster deployment may be sufficient for cloud providers now, but as organizations reach the point where increasingly sensitive data and applications are all that remains to migrate to the cloud, they will quickly reach an impasse,” said Mike Denning, general manager, Security, CA Technologies. “If the risk of breach outweighs potential cost savings and agility, we may reach a point of “cloud stall” where cloud adoption slows or stops until organizations believe cloud security is as good as or better than enterprise security.”

I have so much I’d like to say with respect to these summary findings and the details within the reports, but much of it I already have.  I don’t think these findings are reflective of the larger cloud providers I interact with which is another reason I would love to see who these “cloud providers” were beyond the breakdown of their service offerings that were presented.”

In the meantime, I’d like to refer you to these posts I wrote for reflection on this very topic:

• What People REALLY Mean When They Say “THE Cloud” Is More Secure…
• Cloud Providers Are Better At Securing Your Data Than You Are…
• On-Demand SaaS Vendors Able to Secure Assets Better than Customers?“
• Reprise: On-Demand SaaS Vendors Able to Secure Assets Better than Customers?
• You Can’t Secure The Cloud…

/Hoff

As facetious as the introductory premise of my Commode Computing presentation is, the main message — the automation of security capabilities up and down the stack — really is something I’m passionate about.

Ultimately, I made the point that “security” needs to be as programmatic/programmable, agile, scaleable and flexible as the workloads (and stacks) it is designed to protect. “Security” in this contexts extends well beyond the network, but the network provides such a convenient way of defining templated containers against which we can construct and enforce policies across a wide variety of deployment and delivery models.

So as I watch OpenFlow (and Software Defined Networking) mature, I’m really, really excited to recognize the potential for a slew of innovative ways we can leverage and extend this approach to networking [monitoring and enforcement] in order to achieve greater visibility, scale, agility, performance, efficacy and reduced costs associated with security.  The more programmatic and instrumented the network becomes, the more capable our security options will become also.

I’m busy reading many of the research activities associated with OpenFlow security and digesting where vendors are in terms of their approach to leveraging this technology in terms of security.  It may be just my perspective, but it’s a little sparse today — not disappointingly so — with a huge greenfield opportunity for really innovative stuff when paired with advancements we’re seeing in virtualization and cloud computing.

I’ll relate more of my thoughts and discoveries as time goes on.  If you’ve got some cool ideas/concepts/products in this area (I don’t care who you work for,) post ’em here in the comments, please!

In the meantime, check out: www.openflow.org to get your feet wet.

/Hoff

Reminders to self to perform more research on (I think I’m going to do my next presentation series on this):

• AAA for messages between OpenFlow Switch and Controllers
• Flood protection for controllers
• Spoofing/MITM between switch/controllers (specifically SSL/TLS)
• Flow-through (ha!)/support of OpenFlow in virtual switches (see 1000v and Open vSwitch)
• (per above) Integration with VN-Tag (like) flow-VM (workload) tagging
• Integration of Netflow data from OpenFlow flow tables
• State/flow-table convergence for security decisions with/without cut-through given traffic steering
• Service insertion overlays for security control planes
• Integration with 802.1x (and protocol extensions such as TrustSec)
• Telemetry integration with NAC and vNAC
• Anti-DDoS implications

Related articles

• Big Shots Start New Cloud Standards Body (java.sys-con.com)
• Openflow: Internet 3.0? (zdnet.com)
• Tech Giants Push Smart Networking Standard (informationweek.com)
• OpenFlow: The NoSQL of Network Protocols (readwriteweb.com)
• How Software Will Redefine Networking (gigaom.com)

Image via Wikipedia

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?

/Hoff

Related articles

• Spotcloud launches cloud computing clearinghouse (zdnet.com)
• Are There Tax Breaks in The Cloud? (datacenterknowledge.com)
• SpotCloud Launches Today: What Kind Of An Impact Will It Have? (cloudave.com)
• ComputeNext: Google For Compute Resources (cloudave.com)
• ScaleUp Enables A Federated Cloud Ecosystem (diversity.net.nz)
• Dark Clouds: Can you trust the Cloud? Panel on Feb 4th at Cloud Communications Summit in Miami (voipsa.org)

This is probably my most favorite presentation I have given.  It was really fun.  I got so much positive feedback on what amounts to a load of crap. 😉

This video is from the Cloud Security Alliance Summit at the 2011 RSA Security Conference in San Francisco.  I followed Mark Benioff from Salesforce and Vivek Kundra, CIO of the United States.

Here is a PDF of the slides if you are interested.

Part 1:

Part 2:

Related articles

• My Warm-Up Acts at the RSA/Cloud Security Alliance Summit Are Interesting… (rationalsurvivability.com)
• George Carlin, Lenny Bruce & The Unspeakable Seven Dirty Words of Cloud Security (rationalsurvivability.com)
• Incomplete Thought: Why Security Doesn’t Scale…Yet. (rationalsurvivability.com)

Image via Wikipedia

Every day for the last week or so after their launch, I’ve been asked left and right about whether I’d spoken to CloudPassage and what my opinion was of their offering.  In full disclosure, I spoke with them when they were in stealth almost a year ago and offered some guidance as well as the day before their launch last week.

Disappointing as it may be to some, this post isn’t really about my opinion of CloudPassage directly; it is, however, the reaffirmation of the deployment & delivery models for the security solution that CloudPassage has employed.  I’ll let you connect the dots…

Specifically, in public IaaS clouds where homogeneity of packaging, standardization of images and uniformity of configuration enables scale, security has lagged.  This is mostly due to the fact that for a variety of reasons, security itself does not scale (well.)

In an environment where the underlying platform cannot be counted upon to provide “hooks” to integrate security capabilities in at the “network” level, all that’s left is what lies inside the VM packaging:

1. Harden and protect the operating system [and thus the stuff atop it,]
2. Write secure applications and
3. Enforce strict, policy-driven information-centric security.

My last presentation, “Cloudinomicon: Idempotent Infrastructure, Building Survivable Systems and Bringing Sexy Back to Information Centricity” addressed these very points. [This one is a version I delivered at the University of Michigan Security Summit]

If we focus on the first item in that list, you’ll notice that generally to effect policy in the guest, you must have a footprint on said guest — however thin — to provide the hooks that are needed to either directly effect policy or redirect back to some engine that offloads this functionality.  There’s a bit of marketing fluff associated with using the word “agentless” in many applications of this methodology today, but at some point, the endpoint needs some sort of “agent” to play*

So that’s where we are today.  The abstraction offered by virtualized public IaaS cloud platforms is pushing us back to the guest-centric-based models of yesteryear.

This will bring challenges with scale, management, efficacy, policy convergence between physical and virtual and the overall API-driven telemetry driven by true cloud solutions.

You can read more about this in some of my other posts on the topic:

• Incomplete Thought: Cloud Security IS Host-Based…At The Moment
• The Security Hamster Sine Wave Of Pain: Public Cloud & The Return To Host-Based Protection…
• Where Are the Network Virtual Appliances? Hobbled By the Virtual Network, That’s Where…
• Dear Public Cloud Providers: Please Make Your Networking Capabilities Suck Less. Kthxbye

Finally, since I used them for eyeballs, please do take a look at CloudPassage — their first (free) offerings are based upon leveraging small footprint Linux agents and a cloud-based SaaS “grid” to provide vulnerability management, and firewall/zoning in public cloud environments.

/Hoff

* There are exceptions to this rule depending upon *what* you’re trying to do, such as anti-malware offload via a hypervisor API, but this is not generally available to date in public cloud.  This will, I hope, one day soon change.

Related articles

• Revisiting Virtualization & Cloud Stack Security – Back to the Future (Baked In Or Bolted On?) (rationalsurvivability.com)
• From the Concrete To The Hypervisor: Compliance and IaaS/PaaS Cloud – A Shared Responsibility (rationalsurvivability.com)
• CloudPassage Halo-SVM and Fireware target cloud security (zdnet.com)
• Incomplete Thought: Why Security Doesn’t Scale…Yet. (rationalsurvivability.com)
• What’s The Problem With Cloud Security? There’s Too Much Of It… (rationalsurvivability.com)