En Garde!

From Computing to Communicating

Geoffrey Moore doesn't post too frequently on his "Dealing with Darwin" blog, but I enjoy reading when he does. His most recent blog is about the World Economic Forum meeting in Davos and its theme this year on shifting power equations. He calls out one of the more interesting shifts under discussion - "from computing systems that communicate to communication systems that compute."

He goes on to highlight what he sees as the implications of this shift. "For communications vendors ... the opportunity is to smarten their pipes. This entails a migration of value creation into the network, achieved by computing more and more on the data it carries while it is carrying it." Computer companies, he says, have the opposite opportunity - to help drive interactions vs. just feed data into systems.

It strikes me that security companies have been dealing with this shift for years, and in fact living somewhere between these two worlds the whole time. Security's all about understanding traffic patterns, what users are accessing, and even the content itself that's being transported, and then looking at policy to decide if the traffic should be allowed. This process is at the heart of network behavior analysis, network access control, content filtering and management, and other security technologies. And I think Moore's right that vendors living at the ends of this communicate/compute spectrum need to migrate toward the middle and offer a blend of services.

But my favorite part of the post is his last line. He talks about how this shift toward communications affects the power of people. "A connected world places an enormous premium on people who are fluent in communications.... [Moore's emphasis] In sume, if the past few decades were heralded as the revenge of the nerds, the next few will be the revenge of the liberal arts graduates."

As an English major, I couldn't be happier.

--Michelle McLean
mmclean-at-consentry-dot-com

Controlling your "corporate ghosts"

To better understand how IT is thinking about LAN security, ConSentry recently commissioned some independent research to survey IT leaders at enterprises. Just yesterday the full report hit. Part of the survey asked IT staff to quantify the risks and challenges they face:

• so-called "corporate ghosts" represent the biggest threat for data loss
  
  • temporary workers (62% of respondents cite them as the most risky group)
  • guest users (54%)
  • contractors (51%)
• 82% of respondents have such workers on their LANs
• 65% believe network access is getting more diverse and harder to manage

Other parts of the survey discussed techniques IT is seeking to meet these challenges. The most startling finding was this one:

• 94% of companies see an increased need for identity-based control

I found that statistic surprisingly high, given that identity has only recently come into the Network Access Control and LAN security discussion. As the guys on the Digital ID World blog frequently lament,  people have been slow to make this connection.

We're happy to see this evidence that enterprises are beginning to understand how critical it is for identity to be the foundation for applying access controls.

So take a look at the research - and definitely let us know what stands out as you look over the data.

--Michelle McLean
mmclean-at-consentry-dot-com

Managing NAC

Network World's Tim Greene writes a Network Access Control newsletter twice a week, and it's doing a lot to further the discussion around NAC. He's tackling issues like how to buy NAC products, the relative benefits of pre- vs. post-admission functions (he ascribes more value to post-admission features), and how to work with framework architectures like Microsoft NAP.

In today's newsletter, he raises a key issue - how are you going to manage your NAC deployment. He points out that as a NAC deployment increases in scope and policies increase in richness, centralized policy creation and integration with identity stores is crucial.

We couldn't agree more. For Network Access Control to truly be effective, it will ultimately need to be pervasive. So being able to create a policy once and have it deploy to all NAC devices is key to scalability. And even when policies are fairly simple - like guests get Internet access but employees can go anywhere on the LAN - the ability to learn a user's role based on information already available in something like Active Directory is crucial.

Both these features are hallmarks of the ConSentry system, and we're happy to see Tim raising these kinds of real-world issues. IT needs more concrete advice like this on the topics to investigate as they proceed with their NAC projects.

--Michelle McLean
mmclean-at-consentry-dot-com

NAC - High on the 2007 To Do List

The latest column by Computerworld’s “CJ Kelly” about setting priorities for IT projects in the coming year had me sighing in sympathy. The anonymous Ms. C.J. Kelly heads up IT and security at an unnamed state agency, and reading her take on sorting through competing priorities and confusing technologies to chart a course for her organization hit a chord.

I've been fortunate, both as a vendor and when I was an analyst at META Group, to get a lot of time talking with IT folks, and I’m so often struck during those conversations by the range of projects confronting them and by the palpable fear of making a bad call. At one point in her column, CJ laments the immaturity of the NAC framework architectures – both Cisco’s Network Admission Control and Microsoft’s Network Access Protection. She takes some comfort in the fact that Cisco and Microsoft are working together, but I’d offer even more reason to get comfortable with the idea of embarking on a network access control project – NAC appliances.

NAC appliances give an organization a great way to get started with access control. Use an all-in-one platform to tackle a simple project, like separating guests from employees. Or focus on a limited geography, such as a key headquarters location where critical assets need protection. The key to your comfort is knowing that while the appliance doesn't have any dependencies on other technologies such as client software or switch changes, it can work with and complement framework architectures that mature in the future, such as Microsoft’s NAP. Get the control you need now but know you can interoperate with those architectures down the road.

Look for more specifics soon from ConSentry on this interoperability issue, but for now the message is simple: “Come on in – the NAC water’s fine.”

--Michelle McLean

mmclean-at-consentry-dot-com

Bump in the Wire - Not a Speedbump

I read Alan Shimel’s StillSecure blog very frequently and have a lot of respect for his opinion and his command of the state of security. His “Bump in the Wire” blog, though, left me needing to reply. He recaps how IPS moved inline and then became “big boxes” and says any inline device necessarily has scalability issues. He then says ConSentry and other inline security appliances have discovered this issue and now need to either provide their product as a switch or get bought by a switch company.

I’m having a tough time following the logic here. The initial analogy makes sense – IPS did move from out of band to inline. Any effective security device must be inline to enforce policy. The conclusion that being inline necessarily creates scaling issues doesn’t follow, however. Certainly if you’re going to sit inline in the LAN, you need to have an architecture that can keep pace with the LAN's 10 Gbps speeds. And the architecture of most appliances (off-the-shelf CPUs with some custom software on top) would definitely fail to keep up.

But ConSentry’s most significant competitive advantage is our custom silicon – we knew it would take incredible horsepower to enforce identity-based controls at multi-gigabit speeds. So our in-house developed 128-core CPU and programmable ASICs perform massive parallel processing to maintain LAN performance. Actually, adding in the switching proved to be the easy part – we just overlaid all our horsepower and network access control capabilities on top of merchant switch silicon, so we now offer both an appliance (which sits between existing switches) and a secure switch.

So while Alan raises a valid concern – can your security appliance keep up – his conclusion that inline appliances will necessarily have scalability issues and that those issues will dictate a vendor’s future is flawed. As always, though, Alan, I appreciate the dialogue.

--Dan Leary

dleary-at-consentry-dot-com