Illuminations

I'll See Your New Chips, and Raise You...

Eric Ogren has a nice blog over at ComputerWorld, but his post this week left me shaking my head. Eric anticipates that the new generation of Intel and AMD chips with built-in security processing is going to change the playing field for security appliance manufacturers. More importantly, he states, “it is becoming increasingly difficult to justify the large engineering investments in custom-built ASICs or hardware that is not built on a standard platform”. This assertion couldn’t be further from the truth, and doesn’t anticipate where the ultimate direction of all the emerging security services is going. Security has become increasingly complex due to the sophisticatation of blended malware attacks, among other reasons. The increase in mobile systems, as well as non-employees on corporate networks have reduced the effectiveness of the perimeter and requires security services within the network infrastructure. From Nevis’ perspective, the switch is the ideal security enforcement point because it can block threats in microseconds at the lowest common factor, the port. Existing departmental firewalls or out of band appliances cannot keep malware off the network because, by definition, the malware is already inside the corporate LAN before they even detect it. The future of LAN security is a fully secure access layer – both wireless and wired. Many of the people we speak to get this message. Secure switching at wirespeed is now a reality. Many of the traditional switch vendors understand this dynamic and are planning to build ‘stateful’, application aware switches that are secure.

The challenge thus far in the market has been with performance. Obviously switches are blazingly fast and designed with performance and scalability in mind. LAN technologies require high performance and low cost. Traditionally, security products have been low performance and high cost. As security merges into the network fabric, secure switches need to remain cost competitive AND fast. Something has to give.

If you are going to layer in deep packet inspection and analysis, and do it on every packet, you can’t sacrifice the performance that people expect. Access layer switches are now shipping with multiple 10 Gbps interfaces. Many of the fastest IPS devices in the market struggle to cope with this level of traffic. Eric might be surprised to learn that the fastest Intel and AMD silicon can scale to ‘maybe’ 1 Gbps of traffic when running L4-L7 services. How then can we secure tens of gigabits per second of traffic at the access layer, while keeping them cost competitive? The only answer is the development of customized ASICs or multicore processors that have hardware acceleration for the key L4-L7 services.

Nevis was built on the vision of high performance and low cost stateful services. Key to our success has been the development of our SuperNova™ security ASIC – which has 24 cores and 96 threads, architected to drive security services and application recognition. It mght surprise Eric to learn that 10 of Intel’s fastest CPU’s cannot keep up with 1 SuperNova. Don’t believe me, listen to what one of our customers had to say.

10:1 price performance – now that’s impressive.

Welcome Parveen....

So, I see Consentry have a new President and CEO. No announcement, just quietly slipped onto their website Management page. Does this mean that the fanfare and fireworks over their new round of funding had a bittersweet side (where did Tom go?)? Interesting to see that Parveen comes most recently from a fundamental security player (McAfee) and was the founder and CEO of IntruVert, an IDP player. I think they've realised that to be a credible secure switching or LAN security solution you do have to put the fundamentals into the security piece of the equation. Nevis made the investment early on and have maintained that with a cadre of Security educated PhD's and researchers who contribute to the security community on a daily basis, alongside a strong team of networking engineers. To realize the vision of security ubiquity in the network fabric you have to be able to talk the talk and walk the walk.

Welcome to the LAN Security market space Parveen. I look forward to meeting you and hearing your perspective on the evolution of enterprise networking and security.

//Dom

It's NAC survey season...

Tim Wilson over at Dark Reading is reporting on a recent Applied Research West survey on NAC (it sounds like it was sponsored by Symantec, but I'm not sure):

300 security professionals interviewed
70% have already deployed NAC or plan it in the next 12 months
86% had no problem deploying
21% had difficulty integrating with security hardware and software
18% said NAC used too many resources
16% complained of lack of industry standards (Well this flies in the face of all the so called industry experts who keep telling us that no-one will adopt until standards are defined. We all want standards but they take time)
54% want an all in one product from a single vendor (not possible with an out of band vendor I'm afraid, there are too many moving parts)
61% say vendors should adopt standards (I wholeheartedly agree, which is why we continue our efforts with IETF, TCG and Microsoft.)

27% use NAC for guest access
80% use it to prevent unauthorized users accessing the network
66% use it to protect critical business assets and prevent data loss
(this is totally inline (no pun intended) with what we see from our customers)

30% say they have no plans to adopt NAC in next 12 months
35% of those say it's too costly
27% of those say it's not interoperable with their existing infrastructure
20% of those say it's too disruptive
(hmmm, they should take a look at our solution, it addresses all those points)

63 % prefer NAC enforement to take place in the network rather than at the endpoint
(the logical enforcement point since the endpoint can and usually is the place where exploits occur)

We have done our own survey, which was a little more focused, and the results will pubish over the next week or so. Look out for that, it's interesting for trends, but I'd be interested to hear from IT professionals if they think it's in-line (there's that pun again) with their thinking

Overall it sounds like the industry and customers are starting to settle on some fundamental architectural building blocks:

• The primary requirement for NAC is to police unauthorized access and protect critical assets
• Don't rely on enforcement on the endpoint, the network is the place to do it
• Provide a turnkey solution that's easy to drop in
• Build ubiquitous security into the network
• Minimize the resources required to manage NAC
• Plan for interoperability and standards
• Make NAC more affordable

Now I can honestly say, hand on heart (that's a big deal for a marketing guy because we don't have hearts, but if it helps I started life as an engineer), that we have satisfied each and everyone of those requirements. I'm very proud of what we have done to mature NAC beyond it's infancy to a holistic LAN Security solution that can stand up to both technical and fiscal scrutiny. We don't have all the answers (yet), but our architecture and approach will stand the test of time.

//Dom

UPDATE: Tim Greene at NWW has also picked up this story

A switch by any other name....

It was nice to see Consentry finally get a decent win for their NAC Switch.  We've had our fair share of wins with our Secure Switch in the past year, and it's great to see more customers recognise the fact that the switching infrastructure is the perfect place to deliver scalable, ubiquitous advanced services, like security, in the long term.  Many of our own customers, spanning verticals like High Tech, Pharma, Finance/Legal and Outsourcers, have embraced the Secure Switch, and continue to place regular, quarterly repeat orders as they migrate their wiring closet infrastructures.  But let's not detract from the fact that Consentry did some dragon slaying here in the US, and in FSU they found a customer willing to speak with their check book about their dissatisfaction with Cisco's NAC and the lack of identity based services available in switching overall.  This stuff is not easy to do while maintaining switching performance, which is why you have to make an investment in purpose built silicon, rather than using general purpose COTS (commercial off the shelf) chipsets that don't make the grade.

Now, you'll notice that I called the Consentry switch a "NAC Switch" at the start of this post.  This is deliberate despite the fact that they position it as a secure switch.  In the mind of most security and networking professionals we talk to, a secure switch needs to at least attempt to be secure, and it also has to be able to maintain switching performance while delivering that security and other application intelligent services.  Without any pattern matching capabilities, a very large proportion of threats are free to march right through the Consentry NAC switch.  To be fair, I have spoken at a couple of conferences in the recent past with Michelle from Consentry and she openly admits that threat detection and mitigation is not a focus for their company.  They've built in some anomaly detection capabilities for some level of value add, but their focus is clearly NAC and LAN segmentation (it says so right there on their website).  That's why I'm confused as to why they call it something it isn't.  We chose to take a more holistic approach to the problem, so we spent a bit more time on our ASIC and product line.  This enables us to provide threat signature matching to address a broad range of LAN threats, and hardware accelerated application intelligence, all at a full 10Gbps and switching latencies.  When you integrate this functionality and performance together with access control and NAC, and tie in identity at all stages, you get a secure switch worthy of the title.

//Dom

Is your NAC glass half empty or half full??

Mike Fratto wrote an interesting article debating whether NAC is ready for primetime or not, and, unsurprisingly, Mike Rothman congratulates MikeF for having the "stones" to take that position. Personally I don't think this is about stones, pebbles or grains of sand. MikeF makes some very valid points about the readiness of NAC products to address a broad set of use cases in diverse enterprise environments, but he also makes some great points about the readiness of IT teams to implement the technology. In fact in my reading of his article, I think MikeF raises more points about the readiness of Enterprise IT teams for NAC than the products themselves. This is an important point that I think MikeR has missed in this and several of his previous posts. The reality is that just as products have to mature, customers also have to come up to speed on what this new technology can do for them in their environment. The good news is that customers are coming up to speed and fast. Not only that, but they are recognising the potential of the technology and helping to redefine and extend NAC. What's really gratifying is that NAC has evolved more and more into the vision of LAN Security that we set out more than 2 years ago. So, let's get this straight, it's a good thing when our customers come to us and tell us what they need. Sometimes we see a trend that can be applied across many customers and we embrace it because it means we can add value that people will be willing to pay for. We also innovate and take ideas and features back to customers because we think we have seen a way to help that perhaps the customer didn't think technically possible. In this manner, products and markets evolve and the reason I have remained on the vendor side of the industry is because their is no bigger kick than seeing your product being used to solve a problem or create an initiative that wasn't possible before. We are lucky enough to be closely plugged into early adopters and are not only seeing our rate of customer acquisition increase at a very healthy rate, but also a huge increase quarter by quarter in the number of RFI/RFPs that we are being invited to respond to. While not everyone is ready to roll out corporate wide today, many are certainly biting off managable high priority projects and deploying pilots. Our customers range from specific projects with Fortune 100's to full global deployments with large enterprises and campus deployments with medium enterprises. This is perhaps "security incite" that the two Mike's are not a party to so they assume that things aren't moving along. So come on guys, less of the negativity, and start writing about the cool things customers are already doing with our technology rather than the nits about what can't be done. As one of our customers said, "Look at the problem you want to solve, find a vendor who's thinking the same way and that you can partner with and jump in with both feet". If we all sat around waiting for everything to be perfect we'd still be living in caves.

//Dom

Is Secret Sharing for Convenience Really Keeping a Secret?

I grew up with the maxim “security by obscurity bad, real security good” ringing in my head.

That’s why I find it so hard to be amused when I hear arguments that obscurity can provide security if it is more “convenient.” And then I see products that actually embrace security-by-obscurity-for-convenience out there in the market – and being shipped by companies claiming to be security vendors.

This has come up recently in the context of captive portal login certificate warnings. The beauty of captive portal is that it uses a standard Web browser as a nice GUI for someone logging in. Since it talks to a more or less standard Web server, the way to secure passwords sent over the link is to use TLS. But to use TLS, the server needs a public key certificate, and browsers want (or, should want) to verify the names in these certificates and who issued them, mostly for Web commerce but in this case to protect against password sniffing or classic spoofing attacks.

Many products provide a throw-away temporary certificate for evaluation purposes. This almost always is a self-signed certificate so that customer’s passwords are at least encrypted using a new private key for that deployment. But this gives a browser warning about the certificate not having been issued by a known CA.

So some products try to avoid this major inconvenience by using HTTP as the default. Since this is clearly insecure and most customers will want to turn on TLS, these vendors oblige by shipping a “free” certificate. This way customers don’t get the nasty warning and will see the padlock (if they care), and on newer browsers don’t see red backgrounds in their URLs. End of story, security restored.

Unfortunately, it isn’t. These products get rid of the warning by using a vendor public domain name and baking the same certificate into their software. That means everybody has the same private key, too. How many of these customers actually click on the browser padlock and view the name in the certificate? Do you do this when you go to your bank or order on Amazon? Unfortunately, too many people aren’t in the habit.

I was taught that a secret shared with everyone is not a secret at all. If you’re going to provide a security mechanism, do it right – make it clear that what’s shipped by default is strictly for evaluation and let people put in their own real certificate.

That is, if they care about security in the security product they are purchasing. Isn’t that the whole point?