Because of non-disclosure and other confidentiality contracts with various partners, vendors and manufacturers, we’ve had sealed lips for almost exactly 12 months. Now that it’s been made public by the media, I can share a little information with you and explain why I think you should be excited.

What cat is out of the bag now? HP ProCurve’s network access control solution leverages endpoint management technology from StillSecure’s Secure Access solution. Information Week spilled the beans, so to speak, in Mike Fratto’s recent 2008 NAC Survey Analytic Report. (See page 32)

Now, at this point, I can probably lump you into one of three groups… 1) You don’t care or have no clue what this means 2) You care but think this means HP ‘has no NAC’… or group 3) You know about StillSecure’s success and ProCurve’s integration and think this is a great combination.

I’m sure everyone will have their own opinion- I happen to be in Group 3. Why? Because HP has taken the power of their servers, leveraged a very solid endpoint management tool and incorporated a variety of other management and security features by way of their identity management solution.

• The endpoint security. StillSecure’s Safe Access solution has been winning awards and earning stars for years. You can probably Google it, or check out some of Shimel’s blog  posts, such as this one, with 4- and 5-star reviews from SC Magazine. In fact, just this year (and in previous years) Safe Access was voted Best Endpoint Security Solution by SC Magazine and has won numerous other awards and accolades from various analysts and media firms. They have a clean, user-friendly GUI, a solid Linux platform and a variety of testing methods, deployment options and switch integrations. (And no, you don’t need ProCurve switches, the NAC integration is ready for your Cisco, Extreme, or whatever you have).

• User management. Combine one of the highest-rated endpoint security solutions with ProCurve switches, the #2 leader in the switching market (and Magic Quadrant resident) and the full integration with ProCurve’s Identity Driven Manager platform and you have one amazingly capable access control system. With ProCurve IDM, you can integrate directly with their NAC 800 appliance to offer per-user (or per-group) ACLs, QoS, restrictions or priviliges. Rules can be identity-based, time-based, location-based, or a combination of all. And, IDM eases 802.1X integration by offering users a central management and repository for user settings and VLAN assignments; it really is ProCurve’s special sauce and a distinguishing feature.

• Switch security. The integration of advanced switch security functions, such as DHCP snooping, Dynamic ARP protection and dynamic IP lockdown gives ProCurve another leg-up to fight common known attacks for both in-line and out-of-band NAC deployments.

• Zero-day protection. It gets better, the new Dynamic Configuration Arbiter (DCA) functions in ProCurve’s Pro-vision switches gives customers the unique advantage of integrating the NAC and IDM with ProCurve’s Network Immunity Solution (NIM). NIM uses flow analysis from sFlow and network behaviour anomaly detection (NBAD) to detect and automatically remediate on the edge. In English, that means we can use ProCurve’s NIM to detect attacks and take action at the edge port, such as blocking the port, locking out the MAC address of the offender, rate-limiting, or even mirroring the traffic to an IDS for further inspection. The super-nice part is, all the sFlow and NBAD works on wireless too. (Hey Stiennon, did you hear that?)

• Full integration. Unlike some of the other network-based NAC vendors, ProCurve has done an exceptional job of integrating these features and we’ll continue to see more integration in future revisions of the softwares and as more TNC/TCG integration frameworks are released (such as IF-MAP).

I think the strong integration with the infrastructure and the ability to leverage a mature endpoint integrity will make HP a ‘real’ player in the NAC market moving forward.

Not to knock other NAC solutions- Choosing a NAC is like selecting the perfect wine for your dish- there’s no 1 ‘right’ choice for all occasions. Each have their advantages and disadvantages. There are several that have special sauces and you’ll actually be seeing more on that soon…

# # #

Your first real lesson about locking down a host was how to reduce its attack surface. You learned how to disable services using /etc/inetd.conf. Then you learned about rc.d and how to prevent unnecessary services from being launched at startup. Next, maybe you configured the Xserver to disallow remote connections or moved on to removing setuid permissions from files. As you worked, you’d periodically re-scan the box to gauge progress, asking yourself “have I removed everything I don’t need?” The underlying motivation, of course, is that an attacker can’t hack something that isn’t there.

You learned how to extend those concepts to the network — configuring firewall rules, router ACLs, VLANs, etc. Segmenting the network. Creating a DMZ. No need to dwell on this, you get the idea.

Eventually, people realized that applications had an attack surface too. Web servers and application servers got a lot of attention, followed closely by custom web applications. “What do you mean you can execute SQL queries against my database? That’s impossible, I have a firewall!”

Some companies, the ones who could afford it anyway, started to build security into their development cycle. Doing threat modeling during the design phase made sense, because hey, it’s much cheaper to fix security holes in a whiteboard drawing than it is to rewrite your authorization module from scratch after it’s in production.

Let’s talk strictly about custom web applications now. What I’ve observed is that most development groups, even the ones who actively engage in threat modeling, do not understand their web application’s attack surface. The lead architect can whiteboard a high-level diagram of all the major components and how they interact. Individual developers can go a bit deeper, telling you which files they touch, what database permissions they need, or how various pieces of data are encrypted in storage. At the end of this exercise you have a complete picture of the processes, data flows, protocols, privilege boundaries, external entities, and so on, and you’re well on your way to understanding all of the potential attack vectors.

Or are you?

What often gets overlooked or glossed over is the impact of external libraries or packages. Nobody writes everything from scratch. A typical list of third-party libraries for a Java-based Web 2.0 application might include DWR, GWT, Axis, and Dojo, plus about 30 other libraries to do everything from logging to parsing to image manipulation. Nine out of ten times, the libraries will be installed in full, using the default configuration from page one of the README file.

Why is this relevant? Because just as those old Unix boxes exposed unnecessary services, libraries expose unnecessary code. Let’s say you installed Dojo to simplify the process of creating an HTML table with rows and columns that can be sorted on demand. Did you remember to remove all the .js files you didn’t need? Or maybe you installed Axis or DWR or anything else that has its own Servlet(s) for processing requests. Have you compared what that Servlet can do against what you need it to do?

A fictitious example may help illustrate further. Imagine you just downloaded a new library called WhizBang. You follow the installation instructions to define and map two servlets in your web.xml file, WhizServlet and BangServlet, and you configure it to integrate with your web app. After a bit of trial and error, it’s functional. Yay! This is where most developers stop.

Nobody asks, “how much of this do I actually need?” Case in point, what if your application only uses WhizServlet? BangServlet is still exposed, and you don’t even use it! Similarly, what if WhizServlet takes an “action” parameter which can be either “view”, “edit”, or “delete”, and your application only uses “view”? You’re still exposing the other actions to anybody who knows the URL syntax (pretty trivial if it’s open source). You wouldn’t expose large chunks of your own code that you weren’t using, so why should it be any different with libraries?

This post is getting kind of long so I’m going to split it up. In the next post, I’ll continue the discussion of attack surface minimization, as well as some of the tradeoffs that go along with this approach.

Last week in response to Richard Stiennon's glowing write up, I questioned what it is exactly that Rohati does. Well someone from Rohati must have seen it and I was contacted by the Rohati team and offered a peek and a deep explanation of exactly what Rohati does.  So today I had a chance to speak with Shane Buckley, CEO, Prashant Ghandi VP of product management and strategy and Steven Wastie, VP of marketing.  I was impressed that such a triumvirate of power players from the Rohati team took the time to speak to me.  But I guess after I wrote what I did, it was followed up by JJ writing her article on it and than Rothman piling on with his own two cents. 

Give the Rohati team credit for recognizing the power of blogs to influence the influencer and reaching out to stem the tide.  It just goes to show you how far blogging has come. But enough about the power of blogs, lets talk about Rohati.

The best way for me to describe Rohati is that it is layer 7 ACLs to control access to applications.  Where we already have security at the perimeter and at the edge, Rohati is about controlling access at the server/application.  The diagram on the left (click on it to get a bigger version), is a good illustration of how Rohati works. By integrating with LDAPs Rohati can assign you an access policy to any application.  Based upon that Rohati gives a very fine grain level of access control at the application layer.  It acts as a proxy to the app server for both regular and encrypted traffic.  Because the ACLs are on the Rohati box itself, there really is not any integration with switches per say and so no integration worries.

The only problem is that the Rohati box has to be able to handle the traffic flow.  Hence the box is a big honker.  The cheap one is about 20k list I believe and the industrial size version is 80k. This product is aimed squarely at the data center space and is sold through channels.

Will Rohati succeed.  Yes, I think it will.  I think they have taken a unique approach to a security issue that will continue to grow in years to come.  Application access is an area that I think is still up and coming.  In a period of nothing is ever new in security, the Rohati team seems to have found something that has not been done before in a packaged dedicated way like this.  If nothing else, with all of the ex-Cisco folks there, Cisco will eat its young and buy the technology back in.

We will watch Rohati's progress in the months to come.  At the very least, it seems they are blog savvy enough to navigate the waters of social media.  Maybe they will start their own blog soon.

Last week in response to Richard Stiennon's glowing write up, I questioned what it is exactly that Rohati does. Well someone from Rohati must have seen it and I was contacted by the Rohati team and offered a peek and a deep explanation of exactly what Rohati does.  So today I had a chance to speak with Shane Buckley, CEO, Prashant Ghandi VP of product management and strategy and Steven Wastie, VP of marketing.  I was impressed that such a triumvirate of power players from the Rohati team took the time to speak to me.  But I guess after I wrote what I did, it was followed up by JJ writing her article on it and than Rothman piling on with his own two cents. 

Give the Rohati team credit for recognizing the power of blogs to influence the influencer and reaching out to stem the tide.  It just goes to show you how far blogging has come. But enough about the power of blogs, lets talk about Rohati.

The best way for me to describe Rohati is that it is layer 7 ACLs to control access to applications.  Where we already have security at the perimeter and at the edge, Rohati is about controlling access at the server/application.  The diagram on the left (click on it to get a bigger version), is a good illustration of how Rohati works. By integrating with LDAPs Rohati can assign you an access policy to any application.  Based upon that Rohati gives a very fine grain level of access control at the application layer.  It acts as a proxy to the app server for both regular and encrypted traffic.  Because the ACLs are on the Rohati box itself, there really is not any integration with switches per say and so no integration worries.

The only problem is that the Rohati box has to be able to handle the traffic flow.  Hence the box is a big honker.  The cheap one is about 20k list I believe and the industrial size version is 80k. This product is aimed squarely at the data center space and is sold through channels.

Will Rohati succeed.  Yes, I think it will.  I think they have taken a unique approach to a security issue that will continue to grow in years to come.  Application access is an area that I think is still up and coming.  In a period of nothing is ever new in security, the Rohati team seems to have found something that has not been done before in a packaged dedicated way like this.  If nothing else, with all of the ex-Cisco folks there, if nothing else Cisco will eat its young and buy the technology back in.

We will watch Rohati's progress in the months to come.  At the very least, it seems they are blog savvy enough to navigate the waters of social media.  Maybe they will start their own blog soon.

No not Larry Ellison. StillSecure's oracle of NAC, Dave Greenstein, Chief Security Architect at StillSecure. I write and speak a lot about NAC, but Dave actually lives NAC.  He led our development team that developed Safe Access.  Now he is way out in front researching and designing the next generations of Safe Access and our other products.  Dave doesn't comment on my posts a lot. I am always bugging him to start his own blog.  The best I get is occasionally he will write an article or white paper.  So when he commented on Joel Snyder's article on NAC and my comments, I figured it would make sense to give it some main column play.  Here is what Dave had to say:

In order to use NAP you only need server 2008 for the NPS... Your domain and AD can still be 2003 so I think adoption of NAP will be faster for that reason. Also, XP SP3, which has NAP capabilities, adoption should be pretty fast compared to Vista.

On ACLs, I agree with Joel that ACLs are a great way to do things... But not with routers and DHCP enforcement. If you have HP switches or Extreme Switches then you can do dynamic ACLs per port. Similar to how you assign a VLAN via RADIUS attributes, you can assign ACLs for that port in addition to assigning a VLAN. This is great if you have the right switches. It helps protect the other endpoints within a quarantine VLAN and adds an extra layer of security. Cisco switches do not have this capability unless you’re running Cisco NAC and a Cisco ACS server (ugh). So, buy HP and Extreme switches!

What’s more likely to slow NAP adoption down is it’s total lack of endpoint administration... How do you keep track of what endpoints have which problems? How do you get an endpoint on the network in an emergency even if it has an issue? How do you update the SHAs on your thousands of endpoints? There are a whole host of issues not solved by NAP that make it unusable. That’s where products like StillSecure Safe Access come in.

BTW, if you think Dave makes some sense here and would like to hear more from him, let me know and I will coax him into writing some more! I should also add that I twisted his arm to give Safe Access a plug at the end there. Thanks Dave!

The Network World guys have a lengthy transcript of a webinar Joel Snyder of Opus One and Interop Labs talking about his experience with NAC.  Joel says that Microsoft is leading the charge in bringing NAC to market. Not that NAP is a be all and end all of NAC but it is serving as a foundation that other NAC  vendors than build upon.  Joel also talks about his view that he likes to work with ACLs versus VLANs.

There is a ton of good stuff there but I disagree with Joel on two things.  I think NAP will lead to rapid and broad NAP adoption.  But right now Joel suffers from lab-a-titis.  Yes NAP is great in the lab, but who has Vista and Server 2008 in the real world up and running.  Until we see wider adoption of these platforms, NAP will not reach the masses.  Also, I think dealing with ACLs are a bigger pain than VLANs. This is based on hundreds of engagements by StillSecure engineers in setting up NAC environments.  But as I said, if you are interested in NAC have a read, there is lots of good stuff there.

That group had rights install software and drivers. And if you can install software and drivers, then you can elevate yourself to Administrator or SYSTEM. Vista includes a signed installer that allows standard users to install packages signed by a trusted root. (The "Trusted Installer" is a service that has a SID, so you'll see it in the permissions list on various objects throughout the operating system.) The installer validates the signature chain, then elevates itself to perform the actual installation. Now, standard users can install and update approved software without having to grant membership in the too-powerful Power Users group.

We deprecated the Power Users group and removed it wherever we detected it on ACLs. We recommend that you do the same.

More details in these blog postings:

• Power Users are Admins who have not made themselves Admin yet, by Jesper Johannson
• The power in Power Users, by Mark Russinovich