On Flying Pigs, DNSSEC, and embedded versus overlaid security…
I found Thomas Ptacek’s comments regarding DNSSEC deliciously ironic not for anything directly related to secure DNS, but rather a point he made in substantiating his position regarding DNSSEC while describing the intelligence (or lack thereof) of the network and application layers.
This may have just been oversight on his part, but it occurs to me that I’ve witnessed something on the order of a polar magnetic inversion of sorts. Or not. Maybe it’s the coffee. Ethiopian Yirgacheffe does that to me.
Specifically, Thomas and I have debated previously about this topic and my contention is that the network plumbing ought to be fast, reliable, resilient and dumb whilst elements such as security and applications should make up a service layer of intelligence running atop the pipes.
Thomas’ assertions focus on the manifest destiny that Cisco will rule the interconnected universe and that security, amongst other things, will — and more importantly should — become absorbed into and provided by the network switches and routers.
While Thomas’ arguments below are admittedly regarding the "Internet" versus the "Intranet," I maintain that the issues are the same. It seems that his statements below which appear to endorse the "…end-to-end argument in system design" regarding the "…fundamental design principle of the Intenet" are at odds with his previous aspersions regarding my belief. Check out the bits in red.
Here’s what Thomas said in "A Case Against DNSSSEC (A Matasano Miniseries):
…You know what? I don’t even agree in principle. DNSSEC is a bad thing, even
if it does work.How could that possibly be?
It violates a fundamental design principle of the Internet.
Nonsense. DNSSEC was designed and endorsed by several of the
architects of the Internet. What principle would they be violating?The end-to-end argument in system design. It says that you want to
keep the Internet dumb and the applications smart. But DNSSEC does the
opposite. It says, “Applications aren’t smart enough to provide
security, and end-users pay the price. So we’re going to bake security
into the infrastructure.”
I could have sworn that the bit in italics is exactly what Thomas used to say. Beautiful. If, Thomas truly agrees with this axiom and that indeed the Internet (the plumbing) is supposed to be dumb and applications (service layer) smart, then I suggest he should revisit his rants regarding how he believes the embedding security in the nework is a good idea since it invalidates the very "foundation" of the Internet.
I wonder what that’ll do internal networks?
That’s all. CSI is on.
/Hoff
(Written @ Home drinking Yirgacheffe watching UFC re-runs)
If it walks like a duck, and quacks like duck, it must be…?
Seriously, this really wasn’t a thread about NAC. It’s a great soundbite to get people chatting (arguing) but there’s a bit more to it than that. I didn’t really mean to offend those NAC-Addicts out there.
My last post was the exploration of security functions and their status (or even migration/transformation) as either a market or feature included in a larger set of features. Alan Shimel responded to my comments; specifically regarding my opinion that NAC is now rapidly becoming a feature and won’t be a competitive market for much longer.
Always the quick wit, Alan suggested that UTM was a "technology" that is going to become a feature much like my description of NAC’s fate. Besides the fact that UTM isn’t a technology but rather a consolidation of lots of other technologies that won’t stand alone, I found a completely orthogonal statement that Alan made to cause my head to spin as a security practitioner.
My reaction stems from the repeated belief that there should be separation of delivery between the network plumbing, the security service layers and ultimately the application(s) that run across them. Note well that I’m not suggesting that common instrumentation, telemetry and disposition shouldn’t be collaboratively shared, but their delivery and execution ought to be discrete. Best tool for the job.
Of course, this very contention is the source of much of the disagreement between me and many others who believe that security will just become absorbed into the "network." It seems now that Alan is suggesting that the model of combining all three is going to be something in high demand (at least in the SME/SMB) — much in the same way Cisco does:
The day is rapidly coming when people will ask why would they buy a box
that all it does is a bunch of security stuff. If it is going to live
on the network, why would the network stuff not be on there too or the
security stuff on the network box.
Firstly, multi-function devices that blend security and other features on the "network" aren’t exactly new.
That’s what the Cisco ISR platform is becoming now what with the whole Branch Office battle waging, and back in ’99 (the first thing that pops into my mind) a bunch of my customers bought and deployed WhistleJet multi-function servers which had DHCP, print server, email server, web server, file server, and security functions such as a firewall/NAT baked in.
But that’s neither here nor there, because the thing I’m really, really interested in Alan’s decidedly non-security focused approach to prioritizing utility over security, given that he works for a security company, that is.
I’m all for bang for the buck, but I’m really surprised that he would make a statement like this within the context of a security discussion.
That is what Mitchell has been
talking about in terms of what we are doing and we are going to go
public Monday. Check back then to see the first small step in the leap
of UTM’s becoming a feature of Unified Network Platforms.
Virtualization is a wonderful thing. It’s also got some major shortcomings. The notion that just because you *can* run everything under the sun on a platform doesn’t always mean that you *should* and often it means you very much get what you pay for. This is what I meant when I quoted Lee Iacocca when he said "People want economy and they will pay any price to get it."
How many times have you tried to consolidate all those multi-function devices (PDA, phone, portable media player, camera, etc.) down into one device. Never works out, does it? Ultimately you get fed up with inconsistent quality levels, you buy the next megapixel camera that comes out with image stabilization. Then you get the new video iPod, then…
Alan’s basically agreed with me on my original point discussing features vs. markets and the UTM vs. UNP thing is merely a handwaving marketing exercise. Move on folks, nothing to see here.
’nuff said.
/Hoff
(Written sitting in front of my TV watching Bill Maher drinking a Latte)
NAC is a Feature not a Market…
I’m picking on NAC in the title of this entry because it will drive
Alan Shimel ape-shit and NAC has become the most over-hyped hooplah
next to Britney’s hair shaving/rehab incident…besides, the pundits come a-flockin’ when the NAC blood is in the water…
Speaking of chumming for big fish, love ’em or hate ’em, Gartner’s Hype Cycles do a good job of allowing
one to visualize where and when a specific technology appears, lives
and dies
as a function of time, adoption rate and utility.
We’ve recently seen a lot of activity in the security space that I
would personally describe as natural evolution along the continuum,
but is often instead described by others as market "consolidation" due to
saturation.
I’m not sure they are the same thing, but really, I don’t care to argue
that point. It’s boring. It think that anyone arguing either side is
probably right. That means that Lindstrom would disagree with both.
What I do want to do is summarize a couple of points regarding some of
this "evolution" because I use my blog as a virtual jot pad against which
I can measure my own consistency of thought and opinion. That and the
chicks dig it.
Without my usual PhD Doctoral thesis brevity, here are just a few
network security technologies I reckon are already doomed to succeed as
features and not markets — those technologies that will, within the
next 24 months, be absorbed into other delivery mechanisms that
incorporate multiple technologies into a platform for virtualized
security service layers:
- Network Admission Control
- Network Access Control
- XML Security Gateways
- Web Application Firewalls
- NBAD for the purpose of DoS/DDoS
- Content Security Accelerators
- Network-based Vulnerability Assessment Toolsets
- Database Security Gateways
- Patch Management (Virtual or otherwise)
- Hypervisor-based virtual NIDS/NIPS tools
- Single Sign-on
- Intellectual Property Leakage/Extrusion Prevention
…there are lots more. Components like gateway AV, FW, VPN, SSL
accelerators, IDS/IPS, etc. are already settling to the bottom of UTM
suites as table stakes. Many other functions are moving to SaaS
models. These are just the ones that occurred to me without much
thought.
Now, I’m not suggesting that Uncle Art is right and there will be no
stand-alone security vendors in three years, but I do think some of this
stuff is being absorbed into the bedrock that will form the next 5
years of evolutionary activity.
Of course, some folks will argue that all of the above will just all be
absorbed into the "network" (which means routers and switches.) Switch
or multi-function device…doesn’t matter. The "smoosh" is what I’m
after, not what color it is when it happens.
What’d I miss?
/Hoff
(Written from SFO Airport sitting @ Peet’s Coffee. Drinking a two-shot extra large iced coffee)
What Do “Grassy Knees,” a Gartner Analyst, Cuban Garlic Chicken and Poor Fashion Choices Have in Common?
It’s not the sordid tale of lust, information security and circus midgets you might have been expecting from the title, but instead the highlights of a couple of evenings spent entertaining a wayward analyst soul from Phoenix.
Rich Mogull, Gartner analyst and data protection mercenary, was in town for a couple of evenings, and I played cruise ship entertainment director. It’s what I do. If a fellow blogger or security wonk comes to my town, has a few minutes to spare, it’s my self-appointed duty to make damned sure they have a good time.
I’m all about the full disclosure. It’s how we roll.
As Rich so kindly nominated me for "Best Host for Security Geeks in Boston" I must suggest that he plays the role of visiting team quite well. Damned good head on his shoulders, fun dude to talk with and listen to, and should you ever need saving on the side of a snow-covered mountain, it seems that he’s all you’ll ever need.
We had a great dinner at the Naked Fish (which incidentally has nothing to do with my tattoos,) and then ended up closing that down in favor of the hotel bar in Bedford in which we most certainly were the worst dressed amongst the crowd. We executed on the wild tech. guy role very well using every free napkin in the house to scribble the solutions to every known security problem currently defined.
I called Shimmy because whilst late, I suggested I could do his podcast drunk with Rich adding beatbox sound effects in the background. Alan listened to me ramble for 10 minutes before he asked "Who the hell is this!?"
The next night we hit BeanSec! and hooked up with Mike Murray, 78% of Veracode’s employees (except for Wysopal who is now finally too l33t to hang with us) and 46% of Crossbeam’s staff.
I tried for an analyst trifecta:
Jaquith was invited but he was in Utah gettin’ all Mormon’d up. Rothman was, well, not there because BeanSec! is not pragmatic enough. Stiennon was busy securing the network fabric of the entire nation state of Haiti and nobody @ IDC would answer my calls. Ah well.
Despite that, a good time was had by all.
Good seeing you, Rich. Come back sometime…as soon as you add me to your BlogRoll, that is. 😉
/Hoff
(P.S. Just to be clear, a "Grassy Knee" is one of the specialty drinks at the Enormous Room in Cambridge where we hold BeanSec! along with the "Bad Babysitter" and "God in Little Pieces." Any other imaginative definition is your own fault, you perv. That is all.)
Breaking News: SOA, Web services security hinge on XML gateways!
The article below is dated today, but perhaps this was just the TechTarget AutoBlogCronPoster gone awry from 2004?
Besides the fact that this revelation garners another vote for the RationalSecurity "Captain Obvious" (see right) award, the simple fact that XML gateways as a stand-alone market are being highlighted here is laughable — especially since the article clearly shows the XML Security Gateways are being consolidated and bundled with application delivery controllers and WAF solutions by vendors such as IBM and Cisco.
XML is, and will be everywhere. SOA/Web Services is only one element in a greater ecosystem impacted by XML.
Of course the functionality provided by XML security gateways are critical to the secure deployment of SOA environments; they should be considered table stakes, just like secure coding…but of course we know how consistently-applied compensating controls are painted onto network and application architectures.
The dirty little secret is that while they are very useful and ultimately an excellent tool in the arsenal, these solutions are disruptive, difficult to configure and maintain, performance pigs and add complexity to an already complex model. In many cases, asking a security team to manage this sort of problem introduces more operational risk than it mitigates.
Can you imagine security, network and developers actually having to talk to one another?! *gasp*
Here is the link to the entire story. I’ve snipped pieces out for relevant mockery.
ORLANDO, Fla. — Enterprises are moving forward with service
oriented architecture (SOA) projects to reduce complexity and increase
flexibility between systems and applications, but some security pros
fear they’re being left behind and must scramble to learn new ways to
protect those systems from Web-based attacks.<snip>
"Most network firewalls aren’t designed to handle the latest
Web services standards, resulting in new avenues of attack for digital
miscreants, said Tim Bond, a senior security engineer at webMethods
Inc. In his presentation at the Infosec World Conference and Expo, Bond
said a growing number of vendors are selling XML security gateways,
appliances that can be plugged into a network and act as an
intermediary, decrypting and encrypting Web services data to determine
the authenticity and lock out attackers."It’s not just passing a message through, it’s actually taking
action," Bond said. "It needs to be customized for each deployment, but
it can be very effective in protecting from many attacks."Bond said that most SOA layouts further expose applications by
placing them just behind an outer layer of defense, rather than placing
them within the inner walls of a company’s security defenses along with
other critical applications and systems. Those applications are
vulnerable, because they’re being exposed to partners, customer
relationship management and supply chain management systems. Attackers
can scan Web services description language (WSDL) — the XML language
used in Web service calls — to find out where vulnerabilities lie,
Bond said.<snip>
A whole market has grown around protecting WSDL, Bond said.
Canada-based Layer 7 Technologies Inc. and UK-based Vordel are
producing gateway appliances to protect XML and SOAP language in Web
service calls. Reactivity, which was recently acquired by Cisco Systems
Inc. and DataPower, now a division of IBM, also address Web services
security.Transaction values will be much higher and traditional SSL,
security communications protocol for point-to-point communications,
won’t be enough to protect transactions, Bond said.<snip>
In addition to SQL-injection attacks, XML is potentially
vulnerable to schema poisoning — a method of attack in which the XML
schema can be manipulated to alter processing information. A
sophisticated attacker can also conduct an XML routing detour,
redirecting sensitive data within the XML path, Bond said.Security becomes complicated with distributed systems in an
SOA environment, said Dindo Roberts, an application security manager at
New York City-based MetLife Inc. Web services with active interfaces
allow the usage of applications that were previously restricted to
using conventional custom authentication. Security pros need new
methods, such as an XML security gateway to protect those applications,
Roberts said.<snip>
Reduce Insider Threat in Data Centers — No Oxygen for you today!
The CeBIT show produces yet another gem for Das Blog today. It harkens references to that Seinfeld episode regarding the Soup, um, Dictator (don’t want to offend my German friends.) This time, it’s not about Soup. It’s about good ol’ atmosphere.
A German company has produced a fire prevention system called OxyReduct that functions by reducing the amount of oxygen in a data center. When Oxygen content hits a certain level, things don’t burn.
Sounds simple, eh. It’s a prevention system because it inhibits combustion, not contain/suppress it like Halon/FM-200/Inergen.
Wagner Alarm and Security Systems claims that they can reduce the percentage of oxygen from the normal 21% to 15% where even cables won’t ignite. You can read how via the link above.
Interestingly, they suggest that 13-17% oxygen corresponds to a human-tolerable working condition as approved by "unions." Well, they are Germans…I suppose this is accurate if your definition of "safe" or "tolerable" does not include the need to breathe without gasping.
I just returned from climbing Mt. Meru (~15,000 feet) and Mt. Kilimanjaro (~20,000 feet) and may I suggest that the effects of even mild altitude sickness is unpleasant at the best case and includes projectile vomiting (from multiple orifices) and migraines at the worst. Luckily, I didn’t suffer from any of these symptoms, but many an Austrian tourist I witnessed was not particularly happy without their Diamox tablets.
There’s not much in the way of "’acclimatization" that a data center employee can go through before a shift in the ol’ NOC, so I’m very interested in hearing from anyone who’s spent anytime in a low oxygen environment trying to administer critical infrastructure.
By the way, the supposed low-oxygen environment didn’t work out too well in this blog entry I titled "Ode to a Suppressant."
/Hoff
John Thompson’s (Symantec) Ironic warning of “Conflict of Interest”
Infoworld ran an interesting article on John Thompson’s recent CeBIT keynote in which he took a shot at Microsoft by suggesting that there is an inherently "…huge conflict of interest for one company to provide both an operating platform and a security platform."
I suppose that opinion depends upon whether or not said company suggests that their security controls are all that are needed to secure said operating system or that defense in depth is not needed.
Here’s why I find this statement interesting and I am going to twist it by agreeing with the statement within the context of the same argument pertaining to Cisco as an extension to the many, many articles I have already written on this topic.
Given just the last rash of vulnerabilities in Cisco’s routing, switching and security products a few weeks ago, I believe it’s also a mistake (you can read "conflict of interest" if you desire) for Cisco (le fox) to protect the network (le chicken.) That’s the same argument of the "operating system" and the "security platform."
I think it’s simply not relevant or appropriate to simply shrug off issues like this just because of Cisco’s size and the apparent manifest destiny associated with security "going into the switch" — just because it does and more than likely will — does not mean it should and does not mean that people will settle for "good enough" security when the network consistently fails to self-defend.
I don’t disagree that more and more security *will* make it’s way into the network switches, much like I don’t disagree that the sun will rise in the east and set in the west, but much in the same way that folks don’t just give up and go to sleep once the sun goes down, the lightbulb that goes on in my head suggests there is a better way.
/Hoff
How to make a Security Sandwich out of Ron Gula and Stephen Toulouse? Just add Hoff…
Firstly, my apologies to both Ron and Stephen for the grotesque visual…especially when you consider that this ridiculous analog is all the more absurd when you consider that I’m suggesting I’m the bologna in the middle.
Ew.
As I write this, I regret it immediately.
I’m referring to being included — along with the usual cast of characters; Rothman, Shimel, Williams, Stiennon, etc. — in ITSecurity.com’s Top 59 Influencers in IT Security listing. I’m #24, right in between Gula and Toulouse! This is how we roll, yo!
I’m sure Alan’s going to complain that Amrit beat him out for #1, but I find it hysterical that John Thompson and Tom Noonan are below me! Technically, I’m listed twice; once in the bloggers section and again under the Corporate Security Officers section.
The only way this list is in actual order of anything is the possibility that the ranking represents the number of complaints regarding content from my rabid blog readership of 4 (and you know who you are.) Nonetheless, thanks for voting 6 times each, ya’ll!
You can check out this interesting list of people here.
/Hoff
Massive Security Blog Consolidation Underway: RationalSecurity to Acquire “StillSecure After All These Years” Blog
BOSTON MA, March 3 /PRNewswire/ - Rational Security
BlogoDomination Corp. (RSBC) announced its intention
today to continue the expansion of its consolidation
strategy in the overly saturated Security Blog Market
with the unsolicited hostile takeover bid and acquisition
of Alan Shimel's "StillSecure After All These Years
(SSAATY)" Blog.
Christofer Hoff, CEO and Dark Overlord of the Security
Blogsolidation Dominion, today announced that upon
release of SSAATY's recent earnings report showing a
marked uptake in revenues with income hovering at over
$18 per month, that RSBC would offer an unheard of 20X
revenue multiplier in a stock-for-stock exchange and
an "I (heart) NAC" bumper sticker.
Alan Shimel, SSAATY's CEO/CTO/CMO/CIO/CFO/CSO refused
comment other than to crisply and vehemently reject
Hoff's bid citing unacceptable terms; balking at only a
20X multiplier, he pointed to Ken Xie's $4B sale of
NetScreen to Juniper and suggested that Hoff "...get real if he expects this bulls**t
takeover attempt to warrant any sort of attention other than a trackback and lower
Technorati rating."
Art Coviello, CEO of RSA, complemented his prognostications from his recent 2007 RSA
Security Conference keynote wherein he stated that there would there not be any
independent security companies in 3 years, and Hoff's RSBC would "...subsume all
security blogs within the same timeframe." Mike Rothman was quoted as "...not giving
a crap because neither of them purchased a copy of the P-CSO."
Hoff's response was just as shrill, "If Shimel doesn't pony up like the little bitch
that he is, I'll buy his lap dog Mitchell's blog instead."
Contact:
Christofer Hoff Alan Shimel
CEO and Dark Overlord of the Security CEO/CTO/CMO/CIO/CFO/CSO
Blogsolidation Dominion StillSecure After All These Years
satanwithacheckbook@packetfilter.com finallygotanexit@stillsecureafteralltheseyears.com
Thomas and I were barking at each other regarding something last night and today he left a salient and thought-provoking comment that provided a very concise, pragmatic and objective summation of the embedded vs. overlay security quagmire:
I couldn’t agree more. Most of the security components today, including those that run in our little security ecosystem, really don’t intercommunicate. There is no shared understanding of telemetry or instrumentation and there’s certainly little or no correlation of threats, vulnerabilities, risk or disposition.
The problem is bad inasmuch as even best-of-breed solutions usually
require box sprawl and stacking and don’t necessarily provide for a
more secure posture, especially within context of another of Thomas’
interesting posts on defense in depth/mesh…
That’s changing, however. Our latest generation of NPMs (Network Processing Modules) allow discrete security ISV’s (which run on intelligently load-balanced Application Processor Modules — Intel blades in the same chassis) to interact with and control the network hardware through defined API’s — this provides the first step in that common telemetry such that while application A doesn’t need to know about the specifics of application B, they can functionally interact based upon the common output of disposition and/or classification of flows between them.
Later, they’ll be able to perhaps control each other through the same set of API’s.
So, I don’t think we’re going to solve the interoperability issue completely anytime soon inasmuch as we’ll go from 0 to 100%, but I think that the consolidation of these functions into smaller footprints that allow for intelligent traffic classification and disposition is a first good step.
I don’t expect Thomas to agree or even resonate with my statements below, but I found his explanation of the problem space to be dead on. Here’s my explanation of an incremental step towards solving some of the bigger classes of problems in that space which I believe hinges on consolidation of security functionality first and foremost.
The three options for reducing this footprint are as follows:
Pros: Supposedly less boxes, better communication between components and good coverage
given the fact that the security stuff is in the infrastructure. One vendor from which you get
your infrastructure and your protection. Correlation across the network "fabric" will ultimately
allow for near-time zoning and quarantine. Single management pane across the Enterprise
for availability and security. Did I mention the platform is already there?
Cons: You rely on a single vendor’s version of the truth and you get closer to a monoculture
wherein the safeguards protecting the network put at risk the very assets they seek to protect
because there is no separation of "church and state." Also, the expertise and coverage as well
as the agility for product development based upon evolving threats is hampered by the many
moving parts in this machine. Utility vs Security? Utility wins. Good enough vs. Best of breed?
Probably somewhere in between.
Pros: Reduced footprint, consolidated functionality, single management pane across multiple
security functions within the box. Usually excels in one specific area like AV and can add "good enough" functionality as the needs arise. Software moves up and down the scalability stack depending upon performance needed.
Cons: You again rely on a single vendor’s version of the truth. These boxes tend to want to replace switching infrastructure. Many of these platforms utilize ASICs to accelerate certain functions with the bulk of functionality residing in pure software with limited application or network-level intelligence. You pay the price in terms of performance and scale given the architectures of these boxes which do not easily allow for the addition of new classes of solutions to thwart new threats. Not really routers/switches.
Pros: The customer defines best of breed and can rapidly add new security functionality
at a speed that keeps pace with the threats the customer needs to mitigate. Utilizing a scalable and high-performance switching architecture combined with all the benefits
of an open blade-based security application/appliance delivery mechanism gives the best of all
worlds: self-healing, highly resilient, high performance and highly-available while utilizing
hardened Linux OS across load-balanced, virtualized security applications running on optimized
hardware.
Cons: Currently based upon proprietary (even though Intel reference design) hardware for
the application processing while also utilizing proprietary networking switching fabric and
load balancing. Can only offer software as quickly as it can be adapted and tested on the
platforms. No ASICs means small packet performance @ 64byte zero loss isn’t as high as
ASIC based packet-forwarding engines. No single pane of management.
I think that option #3 is a damned good start towards solving the consolidation issues whilst balancing the need to overlay syngergistically with the network infrastructure. You’re not locked into single vendor’s version of the truth and although the hardware may be "proprietary," the operating system and choice in software is not. You can choose from COTS, Open Source or write your own, all in an scaleable platform that is just as much a collapsed switching/routing platform as it is a consolidated blade server.
I think it has the best chance of evolving to solve more classes of problems than the other two at a rate and level of cost-effectiveness balanced with higher efficacy due to best of breed.
This, of course, depends upon how high the level of integration is between the apps — or at least their dispositions. We’re working very, very hard on that.
At any rate, Thomas ended with:
I like NAT. I think this is Paul Francis. The IETF has been hijacked by aliens, actually, and I’m getting a new tattoo: