Interpretation is left as an exercise for the reader 😉 This went a tad bacterial (viral is too strong of a description) on Twitter:
Interpretation is left as an exercise for the reader 😉 This went a tad bacterial (viral is too strong of a description) on Twitter:
I hope you enjoy the story; its a retrospective regarding the beginnings of security in the virtual space, where we are now, and we we’re headed.
I tried very hard to make this a vendor-neutral look at the state of the union of virtual security.
I hope that it’s useful.
You can find the story here.
Here’s an interesting resurgence of a security architecture and an operational deployment model that is making a comeback:
Requiring VPN tunneled and MITM’d access to any resource, internal or external, from any source internal or external.
While mobile devices (laptops, phones and tablets) are often deployed with client or client-less VPN endpoint solutions that enable them to move outside the corporate boundary to access internal resources, there’s a marked uptake in the requirement to require that all traffic from all sources utilizing VPNs (SSL/TLS, IPsec or both) to terminate ALL sessions regardless of ownership or location of either the endpoint or the resource being accessed.
Put more simply: require VPN for (id)entity authentication, access control, and confidentiality and then MITM all the things to transparently or forcibly fork to security infrastructure.
The reasons are pretty easy to understand. Here are just a few of them:
…so how are folks approaching this?
Easy. They simply require that all sessions terminate on a set of [read: clustered & scaleable] VPN gateways, selectively decrypt based on policy, forward (in serial or parallel) to any number of security apparatus, and in some/many cases, re-encrypt sessions and send them on their way.
We’ve been doing this “forever” with the “outside-in” model (remote access to internal resources,) but the notion that folks are starting to do this ubiquitously on internal networks is the nuance. AVC (application visibility and control) is the inside-out component (usually using transparent forward proxies with trusted PAC files on endpoints) with remote access and/or reverse proxies like WAFs and/or ADCs as the outside-in use case.
These two ops models were generally viewed and managed as separate problems. Now thanks to Cloud, Mobility, virtualization and BYOE (bring your own everything) as well as the more skilled and determined set of adversaries, we’re seeing a convergence of the two. To make the “inside-out” and “outside-in” more interesting, what we’re really talking about here is extending the use case to include “inside-inside” if you catch my drift.
Merging the use case approach at a fundamental architecture level can be useful; this methodology works regardless of source or destination. It does require all sorts of incidental changes to things like IdM, AAA, certificate management, etc. but it’s one way that folks are trying to centralize the distributed — if you get what I mean.
I may draw a picture to illustrate what I mean, but do let me know if either you’re doing this (many of the largest customers I know are) if it makes sense.
P.S. Remember back in the 80’s/90’s when 3Com bundled NIC cards with integrated IPSec VPN capability? Yeah, that.
I could probably just ask this of some of my friends — many of whom are the best in the business when it comes to Red Teaming/Pen Testing, but I thought it would be an interesting little dialog here, in the open:
When a Red Team is engaged by an entity to perform a legally-authorized pentest (physical or electronic) with an explicit “get out of jail free card,” does that change the tactics, strategy and risk appetite of the team were they not to have that parachute?
Specifically, does the team dial-up or dial-down the aggressiveness of the approach and execution KNOWING that they won’t be prosecuted, go to jail, etc.?
Blackhats and criminals operating outside this envelope don’t have the luxury of counting on a gilded escape should failure occur and thus the risk/reward mapping *might* be quite different.
To that point, I wonder what the gap is between an authorized Red Team action versus those that have everything to lose? What say ye?
Namely, hundreds of detailed discussions (read: lots of booze and whining) over the last 5 years has resulted in the following:
Most in-line security appliances (excluding firewalls) with the ability to actively dispose of traffic — services such as IPS, WAF, Anti-malware — are deployed in “monitor” or “learning” mode are rarely, if ever, enabled with automated blocking. In essence, they are deployed as detective versus preventative security services.
I have many reasons compiled for this.
I am interested in hearing whether you agree/disagree and your reasons for such.
Augmentation, extension, lensless optics you blink through
Winking gestures, #hashtagged pictures, an earpiece you talk to
It gives you directions, sends you tweets, you’ll hangout!
Wifi and bluetooth, “PEACOCK!” its users all shout
“Don’t diss the tech, man,” the fanbois decree
You’ve nothing to fear…except privacy
They’re a curious bunch, these intrepid explorers
While last week’s cool toys now lay dusty and choreless
Want lunch? Movie review? Need directions? A clue?
You needn’t ask, they’ll just Glass it for you.
They look down when they speak and up when they Glass
Don’t take offense, they’re not being an ass
There’s two planes of existence, “outside Glass” and thus “through”
They live on one side, on the other, there’s you
The worldwide web at you pupil-tips, it sounds quite the perk
Til you end up all cross-eyed, like Steve Martin’s “The Jerk”
Glassdebating on Twitter…it seems to last for hours
Those in technorapture post pics of themselves in showers
The experience, transcendent, it seems quite zen
But the users seem to be just middle-aged white men
We’ve already got Aspies, the socially inept
Now we’ll bear witness with those with whom you’ve slept
They’ll be segregated seating; “Glass OK” and “No Glass”
The have’s and the have-not’s, it’s gonna be crass
As social interaction becomes more and more abstracted,
people wearing Glass will converse with others much distracted
Are you recording? Is that thing on? Are you Googling me as we speak?
At first it seems quite quaint, a parlor trick for geeks
And then as comfort and fashion sense collide and people will withdraw,
alas some good technology, will not seem cool much more
You’ll pull out a smart phone, look like a T-Rex
While a Glasshole whispers snidely “Bet he still codes in hex!”
Those who hold out will proudly boast along with loud retort:
“Hey man, I’m not tethered, this ain’t Minority Report!”
“OK Glass” is a statement, a command, so stop hating.
To some it’s a class thing, a tech thing, to some it’s berating
If your perspective is at just one end of the spectrum,
the schism of your prism could have you kicked in the rectum
At the end of the day, it’s a magnificent tool
some think it obtuse, some think it quite cool
For me and my smartphone with my old school connection
I feel no need for this UX inflection
I have some serious things I’ll say about this after being accosted for my opinions — which I actually researched by having Adrian let me use his Glass.
I’ll talk about that soon.
Oh, and if you haven’t seen these:
…you really ought to
For those of you who haven’t seen me speak, Bluehat generally brings out the best in me and happens to capture it on video and make it available for you!
Here you go (link if you can’t see the embedded video below):
This is deliciously ironic.
Intel‘s implementation of the TCG-driven TPM — the Trusted Platform Module — often described as a hardware root of trust, is essentially a cryptographic processor that allows for the storage (and retrieval) and attestation of keys. There are all sorts of uses for this technology, including things I’ve written of and spoken about many times prior. Here’s a couple of good links:
But here’s something that ought to make you chuckle, especially in light of current news and a renewed focus on supply chain management relative to security and trust.
The Intel TPM implementation that is used by many PC manufacturers, the same one that plays a large role in Intel’s TXT and Mt. Wilson Attestation platform, is apparently…wait for it…manufactured in…wait for it…China.
I wonder how NIST feels about that? ASSurance.
Talk amongst yourselves.
In the networking world, we’ve seen how virtualization technologies and operational models such as cloud have impacted the market, vendors and customers in what amounts to an incredibly short span of time.
What’s popped out of that progression is the hugely disruptive impact of Software Defined Networking and corresponding Network Function Virtualization. These issues are forcing both short and long term disruption in the networking space. Behemoths have had to pivot…almost overnight. We haven’t seen this behavior for a while.
I’m curious as to what people see in terms of technology that they feel is truly disruptive to the Security industry. That means you.
I understand many use cases, trends and operational shifts such as BYOD, Mobility, Cloud, etc. as well as amplification of “older” issues such as DDoS, Malware, WebApp attacks, etc., but I’m curious if you think we are really seeing truly security technology disruption impact that is innovative versus incremental advancement (on either the offensive or defensive side of the coin.)
You have an opinion?
As I continue to think about the opportunities that Software Defined Networking (SDN) and Network Function Virtualization (NFV) bring into focus, the capability to deliver security as a service layer is indeed exciting.
I wrote about how SDN and OpenFlow (as a functional example) and the security use cases provided by each will be a differentiating capability back in 2011: The Killer App For OpenFlow and SDN? Security, OpenFlow & SDN – Looking forward to SDNS: Software Defined Network Security, and Back To The Future: Network Segmentation & More Moaning About Zoning.
Recent activity in the space has done nothing but reinforce this opinion. My day job isn’t exactly lacking in excitement, either
As many networking vendors begin to bring their SDN solutions to market — whether in the form of networking equipment or controllers designed to interact with them — one of the missing strategic components is security. This isn’t a new phenomenon, unfortunately, and as such, predictably there are also now startups entering this space and/or retooling from the virtualization space and stealthily advertising themselves as “SDN Security” companies
Like we’ve seen many times before, security is often described (confused?) as a “simple” or “atomic” service and so SDN networking solutions are designed with the thought that security will simply be “bolted on” after the fact and deployed not unlike a network service such as “load balancing.” The old “we’ll just fire up some VMs and TAMO (Then a Miracle Occurs) we’ve got security!” scenario. Or worse yet, we’ll develop some proprietary protocol or insertion architecture that will magically get traffic to and from physical security controls (witness the “U-TURN” or “horseshoe” L2/L3 solutions of yesteryear.)
The challenge is that much of Security today is still very topologically sensitive and depends upon classical networking constructs to be either physically or logically plumbed between the “outside” and the asset under protection, or it’s very platform dependent and lacks the ability to truly define a policy that travels with the workload regardless of the virtualization, underlay OR overlay solutions.
Depending upon the type of control, security is often operationalized across multiple layers using wildly different constructs, APIs and context in terms of policy and disposition depending upon it’s desired effect.
Virtualization has certainly evolved our thinking about how we should think differently about security mostly due to the dynamism and mobility that virtualization has introduced, but it’s still incredibly nascent in terms of exposed security capabilities in the platforms themselves. It’s been almost 5 years since I started raging about how we need(ed) platform providers to give us capabilities that function across stacks so we’d have a fighting chance. To date, not only do we have perhaps ONE vendor doing some of this, but we’ve seen the emergence of others who are maniacally focused on providing as little of it as possible.
If you think about what virtualization offers us today from a security perspective, we have the following general solution options:
There are tradeoffs across each of these solutions; scale, performance, manageability, statefulness, platform dependencies, etc. There simply aren’t many platforms that natively offer security capabilities as a function of service delivery that allows arbitrary service definition with consistent and uniform ways of describing the outcome of the policies at these various layers. I covered this back in 2008 (it’s a shame nothing has really changed) in my Four Horsemen Of the Virtual Security Apocalypse presentation.
As I’ve complained for years, we still have 20 different ways of defining how to instantiate a five-tupule ACL as a basic firewall function.
Out of the Darkness…
The promise of SDN truly realized — the ability to separate the control, forwarding, management and services planes — and deploy security as a function of available service components across overlays and underlays, means we will be able to take advantage of any of these models so long as we have a way to programmatically interface with the various strata regardless of whether we provision at the physical, virtual or overlay virtual layer.
It’s truly exciting. We’re seeing some real effort to enable true security service delivery.
When I think about how to categorize the intersection of “SDN” and “Security,” I think about it the same way I have with virtualization and Cloud:
There are numerous opportunities with each of these categories to really make a difference to security in the coming years.
The notion that many of our network and security capabilities are becoming programmatic means we *really* need to focus on securing SDN solutions, especially given the potential for abuse given the separation of the various channels. (See: Software Defined Networking (In)Security: All Your Control Plane Are Belong To Us…)
Delivering security as a service via SDN holds enormous promise for reasons I’ve already articulated and gives us an amazing foundation upon which to start building solutions we can’t imagine today given the lack of dynamism in our security architecture and design patterns.
Finally, the first two elements give rise to allow us to do things we can’t even imagine with today’s traditional physical and even virtual solutions.
I’ll be starting to highlight really interesting solutions I find (and am able to talk about) over the next few months.
Security enabled by SDN is going to be huge.