Don’t Hassle the Hoff: Recent Press & Podcast Coverage & Upcoming Speaking Engagements
Here are some of the recent press coverage on topics relevant to content on my blog:
- Information Week: Virtualization Has A Security Blind Spot
- Forbes: How To Protect A Company’s Data
- InfoWorld: Defending Security In A Weak Economy
- InfoWorld: Security Futurists Shun Perimeter, Anti-Virus Systems
- CIO: Real Risks Inside Every Virtual Box
- Information Security Magazine: 5 Virtualization Do’s and Don’ts
- SeekingAlpha.com: The Year Of VirtSec So Far
- Virtualization.com: Who Own’s Virtualization Security (Hoff vs. Citrix Debate)
- CSO: How IT Security Pros Blow Off Steam
Podcasts/Webcasts:
- Jericho Forum: Security Roundtable (Available Now)
- Virtualization Security Hits Center Stage: TBA
- Ziff-Davis Virtual Tradeshow: Delivering On the Vision of Business-Driven IT
I am confirmed to speak at the following upcoming events:
- IBM Global Innovation Outlook, Chicago, June 9-10
- Financial Services Information Security Decisions, NY, June 19-20
- Blackhat, Las Vegas, August 2-7
- Defcon, Las Vegas, August 8-10
- IT Security World, San Francisco, September 15-17
- Day-Con II, Dayton, Ohio, October 10-12
/Hoff
Categories: Press, Speaking Engagements
So I was just meandering through the articles and I noticed that in "Virtualization Has a Blind Spot" there was some interesting, and obvious, misconceptions.
From this picture: http://www.informationweek.com/1186/EMC_security_…
They state that the "Server 2" scenario will add "significant delays" in network / processing. So I'm going to say — no, it doesn't. Why? Because if you were to use physically seperated servers and those servers were across multiple VLANs anyway, it really adds no overhead.
And if they're on the same VLAN and you still want to inspect or process that data flow and it's flowing back to the access / core layer you can still pump data through your security devices using VACLs.
I'm in the middle of building out an ASP environment for a large defense corporation right now and although 90% of the server environment is virtualized we're still utilizing all of the network security appliances just as if they were physical boxes. It just takes good up front engineering and people who know how to leverage moving data around the network in efficient methods.
So to blind spot — I say, sure — when you don't know what you're doing.
Kewl. See you in August, for some Hassle-Hoffing.
@windexh8er Perhaps you're missing the context of how the second scenario was painted — and that's in comparison to scenario #1.
Specifically, what they were saying is that if you have NO security functions intercepting traffic between VMa and VMb in Server #1 you have the latency/overhead of the vSwitch/virtualization platform only.
In #2, if you tried to secure intra-vm traffic by using their example external IPS solution, going in and out of the host, to/from the IPS and back for every flow, the latency/overhead imposed here is new and additive.
Then there's scenario #3 which suggests that if you're going to secure intra-vm traffic, you could do it via VM/VA on the host or using API's via the VMM.
They're not comparing it to physical versus virtual, it was virtual vs virtual with the overhead of adding security functionality.
I hope that clears that up.
This is one of the points of my Four Horsemen of the Virtualization Apocalypse post a month or so ago…it's being turned into a whole talk @ Blackhat. Come heckle if you like! 😉
/Hoff
"Don't Hassle the Hoff" is a t-shirt, check it out: http://www.bustedtees.com/hassle
@tybolov: Yep. I know. I have about 4 of them! 😉
Dan Geer sent me a link to one this week, also!
I plan to wear one durin my talk @ blackhat.
😉
@hoff
Makes sense, I guess I just assume comparison (i.e. not the right thing to do) with a non-VM architecture.
The real question is… Do we want the developers writing VM code designing security for us as well (i.e. it's not their forte). And secondly, if they're just providing hooks to pull the data — we all know the API will be under attack at some point. I know, there's never the bullet proof answer and I think hypervisor security is definitely needed. It's just — how do you do it right? I wouldn't want VMWare building my security suite. Not to say they couldn't, but it won't be what it should.
Anywho… Discussion is good — I'd be interested in hearing what you think.
@Windexh8er — In short, it's a balance. I really liken the problem to squeezing a balloon — security being the balloon. Regardless of where security exists, it's really the same problem to solve. you squeeze it in the middle and the air pops out either end… 😉
Here's what I want:
1) I want a secure-as-possible, thin VMM that offers up API's to allow secured access at various levels of control to certain functions provided by the virtualization layer by third party software. This would provide access to not only control functions like fw, ips, etc., but also management apps and detective functions.
2) I want certain features within the VMM itself to provide functionality — capitalizing on the architectural benefits of virtualization — that aren't available in the guest OS's themselves. The memory firewalling/anti-malware stuff we've been teased with would be nice.
…I have other wants/desires/likes, but I'll leave it there for now.
Basically it's the argument I had with Simon. I'm not suggesting that the virtualization platform providers end up as the end-all, be-all of security in the virtualized world, but they ought to give me the flexibility and resiliency options to potentially live up to all those claims of virtualized environments being "more secure" than their physical counterparts…
/Hoff
Hoff-
I think this comment exchange is further validation of your point with Simon. Citrix has plenty of confusion ahead of it in the data center if it doesn't get out front ala VMware on this issue and articulate a vision, put it in practice and bring netsec/virtsec and ops together.
G
@hoff
Thanks for the follow up. From my perspective it would be also nice to allow a pass through solution. To explain, I have two dedicated NICs on the host hardware to allow me to create an egress and ingress for security flow between VMs between VLANs, or routed, for that matter. The platform would allow me to create VLAN trunks or VRF instances out the egress through an array of security devices that are in band to that particular chassis. That way if I'm doing bump-in-the-wire (L2) services I have little, to no, latency issues, aside from the latency that is involved with switched platforms. Even routed brings in minimal latency with today's hardware performance. The thing for me is that you can't generally get something for nothing. Sure, you add a millisecond or two to process off platform — that's justifiable. The thing is say a VM provider is going to say they can offer me IPS services with their product. In todays world you need a pretty beefy box to handle even 1 Gb's worth of deep packet inspection. So putting it on the VM only decreases the available processor, RAM, I/O systems availability to my host VM and guest VMs. Which is why I say you can't get something for nothing… At that point the VM provider has to either create some sort of on board dedicated resources in hardware to provide a "good" solution. Providing the API is somewhat similar… I can either go that route, or seemingly, just create a network security architecture around the platform being built and leverage today's fast switch/route services and take my hit on network latency (minimal) and processing latency (which we'll have no matter if it's in VM or not.
So to sell me on VM security services will be harder than convincing me to design the system to do it off the box. I also get the warm fuzzy that I'm not putting all my eggs in one basket. I can trust that even if the host VM platform is compromised they still can't disable host VM security monitoring.
It's a tough problem, but for now, for what is available my professional recommendation would be to keep things physically separated for the time being.
Great conversation here thus far!
@windexh8er We're TOTALLY on the same page…that's exactly the theme of my 4 Horsemen presentation.
BTW, my recommendation to customers in briefings are aligned with yours for the most part…my preso for the last year has explored these very issues…people leave depressed but edumacated.
It's funny how the vendors don't tell you any of this 😉
The problem of recommending physical separation (at least in the DMZ) is that it directly contradicts the virtualization benefit TCO/ROI initiatives…there are compromises that can be made like overlay solutions such as Crossbeam which work well and balance the two, but they require re-architecture of the networking also.
It's a shame this is buried in this thread. I think I'll bubble it up into it's own…
/Hoff
Ego blogging – when you care enough to let everyone know how important you are =)
@amrit:
Don't hate the player, hate the game.
So if my post is "ego" blogging, does that make your contribution "id"(iot) commentary? 😉
Thanks for dropping by. It's always so good to hear from you!
Now, back to our meaningful dialog spurred by this fathomless need to be famous (and taunted.)
/Hoff.