Anyway, here’s the abstract:

After the endpoint security assessment is over and it’s time to go talk to vendors, how can you tell between a song and a dance, and what you can truly expect out of a product?
Listen to Opus One’s Joel Snyder outline the essential questions to ask prospective vendors when assembling an endpoint security product RFP. Specific points of emphasis include basic product functions, guest users and network management infrastructure integration.

And here’s the link. You will probably have to tell them the name of your first-born child to listen to it. Sorry.

Endpoint security and NAC require taking a lifecycle view of network and client security. It’s not enough to say, “We check your PC and if it’s OK, you get on the network.” Instead, any endpoint security strategy has to be focused on keeping people on the network, not keeping them off. That means building a lifecycle approach, starting with assessment and monitoring, then remediation (if necessary), followed by enforcement integration, all wrapped up within a global policy definition and management structure.

Endpoint security usually begins with posture assessment, and this is the easiest to understand and build into your lifecycle. There are many product choices here, such as installed clients, downloadable bits of software, assessment strategies based on external scanners and vulnerability analyzers. No matter the choice, the goal is to figure out whether someone who wants to connect to the network should be allowed to do so.

Some NAC vendors mistake policy compliance (e.g., does this system have a virus scanner installed?) for safe computing (e.g., is this system infected with a virus?). Don’t let their naïve views of things confuse you. Instead, focus on the lifecycle and realize that even if a machine is found to be acting badly, there are additional tools to help. This is where monitoring, the second part of the endpoint security lifecycle, comes in.

One obvious kind of monitoring can be done on the client itself, assuming an application is running there that can watch the status of the system. Some vendors call that “continuous enforcement;” others use the unwieldy “post-admission NAC” term. No matter how it’s labeled, this part of the lifecycle acknowledges that just because someone smelled nice when they connected doesn’t mean that they’ll always be so sweet.

One problem with software running on or near the network client is that it can lie, or be lied to. A dispassionate third party helps here. Solid NAC strategies have definite feedback loops based on the ability to monitor what is actually happening on the network. You might start with existing IDS sensors and their alerts, or flow data from routers or firewalls. You’ll also find folks with vulnerability analyzers or endpoint discovery tools ready to hook into a good NAC framework to provide further information on the health of a system after it’s been connected.

Any time an endpoint security strategy can result in the prohibition of network access, remediation becomes a mandatory part of the lifecycle. This is one part of NAC where it pays to splurge. You might get away with simply dumping clients onto a VLAN where patches and antivirus updates can be downloaded and applied — at least until someone important is kept from doing their job. But for best success, carefully investigate one of the many commercial tools that can help catch the user’s attention, alert them to what is going on and walk them through whatever it takes to get them onto the network. This is one area of NAC, unfortunately, where an open source approach doesn’t offer the tools that are required.

Remediation strategies should not be based on auto-remediation, whenever possible. Auto-remediation means that the client should automatically update itself and change configurations to bring itself into compliance, as determined by the NAC policy. Auto-remediation is generally possibly only when systems are centrally managed by enterprise IT.

Enforcement integration is always part of an endpoint security strategy. It might be interesting to know that Stacie’s laptop has the wrong version of the antivirus scanner, but it’s a lot more useful to push that information back into the NAC infrastructure so that it can enforce policy. While early endpoint security tools focused more on reporting, the integration between network access control devices and endpoint security detection is a hallmark of modern products. Another key part of the lifecycle is feeding the status of endpoint security into the NAC enforcement mechanism. As the user’s system moves from suspect, to scanned, to remediation, to compliant, NAC enforcement needs to keep up.

Finally, all these pieces need to be wrapped up nicely into a single policy management system. NAC may be bringing together many different components from all over the network, but if there’s no consistent and overarching policy management system, the result will be chaos. This is harder than it seems, not just because of the technical challenges, but also due to organizational barriers. With a proper NAC and endpoint security strategy in place, people ranging from desktop system managers to infrastructure designers to firewall managers are all going to have to sit down and agree to share information and, in some cases, cede a certain amount of control to another group.

Once you’ve created an endpoint security lifecycle, and integrated it into your NAC architecture, you’re one step closer to a successful NAC deployment.

It was great for about two weeks. We had a conference call and a smart SE helped get it installed and we were happy and life was good. Then, 2 weeks later, the power supply pooped out.

We discovered that this vendor’s tech support system is designed to keep people from actually being able to get support. You can’t send email: no address. You can’t call in—the voice mail says “you must use the web.” But you can’t enter a trouble ticket on the web site unless you have an account. Which, because this vendor seems to have a CRM built using punch cards, they had neglected to give us.

A few days later, the sales guy gets back to us—he’s the only person at the company who will actually return our calls—and sets up a support account. Which is groovy and we are finally able to say “our box is broken.” This is progressing nicely down the chain of problem solving until someone realizes that the company my friend works for (a BIG company) is not the same as his consulting company (a very SMALL company) and promptly cancels all of our technical support accounts, closes the call, and now we’re back to square one with a box that doesn’t work, no support, and no returned calls. Skipping some agonizing details, let’s say that saintly sales guy intervenes again and, 5 weeks after our first system dies, we finally get a new one—which, of course, won’t work.

It doesn’t work because the punch-card based CRM system is too stupid to understand that this box replaces the old, dead, box and it won’t let us activate it. Which I can’t fix because we still don’t have technical support turned back on.

What do I do? I give up. Get out a screwdriver, swap the power supplies, put the old box back in place, and get the system back up and running. What should the vendor do? Well, if you’re not going to bother to support small businesses, you should stop taking their money.

NAC Deployment: A Five Step Methodology

Here’s the abstract:

Deployment of Network Access Control (NAC) technology throughout the enterprise is a complex and expensive process. As with any IT project, the success or failure of a NAC deployment will depend, to a great extent, on the design and architecture development processes that take place well before the actual installation begins. This white paper offers a five-step methodology that will position any enterprise for achieving success with its network access control deployment.

Here’s the Executive Summary:

Adding Network Access Control (NAC) to an existing network is a dramatic and significant change to the physical network. When NAC is in place, the network is no longer a neutral substrate for moving packets around as quickly as possible. Instead, it becomes a security barrier; authenticating users, evaluating the security of end-point systems, and applying access controls focused on the user and their security status. A NAC-enabled network is no longer a utility, like power and water, but must be tailored to fit organizationally into networking, security, and desktop management teams to be effective.

This white paper discusses five critical questions that must be answered at the very early stages of any NAC project. These technology-independent questions form the basis of a deployment methodology. By addressing these questions before you’ve picked products or even chosen the IT team members who will be assigned to complete the project, it is very likely that you’ll be able to address the most significant issues your team may encounter along the way to NAC success.

The five questions are:

1) What are your goals for bringing NAC into your network?
2) How will you use user authentication within your NAC policy?
3) How will you tie the End Point Security (also referred to as Posture Assessment) into your NAC policy?
4) Where in your network will you enforce access controls, and how granular will your enforcement be?
5) How will you ensure that your NAC deployment will be implemented systematically across your organization without causing unnecessary interruptions to your existing network?

It’s a strange kind of thing to do for a living—looking at products, trying to use them, put them into production on a real network, try and guess how someone who actually wants to buy them might use them.

Testing products is so easy to do wrong, and it’s hard to do right. Combine in the pressure of hitting a deadline, making it all work on budget, and fitting the results into a tiny number of words… and it’s a wonder that we get anything at all that’s useful to anyone.

But people eat this stuff up. I guess whether they know or not, they realize that doing what we do as product testers would be tough work. So back to the lab I go, trying to put it all into perspective, trying to generate something useful.

It’s hard work, and it doesn’t pay near what it costs, but it’s important. Of course, the junk out there will all eventually disappear on its own, but I’ve discovered that the good guys have to be called to account as well. Not just on bugs and security problems (there’s a bunch of people who love to deal with *that* little nightmare), but also on product design.

Along the way I’ve made some awful enemies. Tell someone that their baby is ugly, and they can’t ever forgive you. Especially if you say it in public. And, I’ve made some great friends (even people who had ugly babies). A good engineer or designer or manager thrives on feedback, and can build better products because of it.

• The conflict between monitoring and privacy. Two huge trends — data protection with encryption and content inspection in the network — are beginning to collide in many companies. Examining content as it flies across the network, looking for malware or spam, logging for regulatory reasons, watching for intrusions and keeping track of resources is getting popular. But examining content depends on being able to see the content. At the same time, the use of encryption in Web, e-mail, instant messaging and every other application is increasing—and if the traffic is encrypted, you can’t see it.

There are piles of products and ideas on how to deal with this conflict, but nothing has bubbled up that has made any sense. Some of the suggestions are even outright absurd, such as blocking all encryption. The reality is that there’s no easy answer coming out of this collision between technology and politics. I hate describing problems without offering a solution, but all I can advise here is to start thinking about building your own compromise between these two trends—because if you haven’t started that balancing act yet, you probably will soon.

• The conflict between security resources and requirements. For most companies, every dollar spent on security seems like a wasted one. Security is often like insurance: money you spend now to avoid a much bigger and more catastrophic expense later. Unfortunately, the expensive war between malicious hackers and enterprise companies is escalating, and the bad guys have the advantage. Doing security well requires ever more sophisticated staff to understand how to build a deep defense and ever more expensive tools to implement that defense. Pressure to increase security controls is also coming from other fronts, such as the regulatory and legal side of the business.

Our old standbys — a three-zone firewall and a copy of Snort — aren’t good enough. As security guru Gregory Lebovitz says, “Swiss army knives are good for a great many things, but slicing an 80-pound wheel of Parmesan for a 500-person party is not one of them.” Even if you can afford the specialized products—and more are coming out every day—you also need to budget for training, support and most expensive of all, staff time. That’s assuming you can find the people out there who can actually understand, configure, manage, and interpret the output from all this new hardware and software. Network access control (NAC) is a good example. We didn’t need it before, but we think we need it now. Lots of money, time and aggravation make sense to those of us down in the trenches, because we have to paddle ever faster just to stay in place, counter new threats and secure newly business-critical networks. But that doesn’t make it any easier to explain to the CFO.

So, I’m a T-Mobile Data customer, and I have the Hot Spot service which I seem to be able to use in every other airport in the US and a lot of them overseas. I launched up by little browser and up came this message from Logan Airport:

OK, so they don’t have *my* roaming partner, but they at least are asking for feedback. Or they seem to be… (that’s foreshadowing for you in case you missed it)

Here goes:

And then I press the submit button and learn the truth about things. Logan doesn’t really want to know what you think.

The frightening thing is that probably someone is telling the boss that everyone loves the WiFi and they really get very little negative feedback.

Evaluating Unified Threat Management Products for Enterprise Networks

Here’s the Overview:

The term Unified Threat Management (UTM) has as many meanings as there are products that carry that label. While UTM has primarily focused on the small- and medium-sized network, products are coming to market that aim at the enterprise. This white paper will help you understand the specific issues that enterprises need to consider when looking at UTM products, and offers guidance on evaluation criteria for enterprise-class UTM.

At its core, UTM brings together three main ideas: multiple security features, integrated on the basis of a mature firewall, deployed in an appliance form-factor. The intuitive appeal of UTM is obvious: why have two (or three or four) boxes performing separate functions, when a single box will do? As security threats to corporate networks have increased at an alarming rate, the number of devices to combat these threats has grown at nearly the same speed. However, at some predictable point, it’s not feasible to have every new threat addressed by its own dedicated device.

The reasoning behind UTM has resonated strongly with managers commanding small and medium-sized business (SMB) networks, where UTM firewalls—called such because the firewall is the undisputed lynchpin of the UTM product— have quickly become a standard offering from every vendor. In this market space, UTM firewalls, with combined features that include anti-virus protection and intrusion prevention built in to the same appliance, both reduce costs and simplify configuration.

UTM products in larger enterprise networks areisn’t an easy sell primarily because most UTM products are indeed aimed directly at the SMB environment and enterprise network and security managers haven’t had reason to view them as appropriate parts of their security strategy. Fortunately for the higher end, this product deficit is quickly changing, as enterprise-class firewall vendors are adding UTM features to their product lines. [[This is a place where we could list enterprise UTM products.]].

Obviously, evaluation and design criteria for UTM in enterprise networks must be very different from those of SMB-sized networks. When UTM concepts are brought to bear on large networks, in ways appropriate to those networks, they offer the network and/or security architects’ tremendous flexibility to control and mitigate the risks associated with security vulnerabilities.

Because UTM, in general, and especially UTM in enterprise networks, is new, network managers need a framework to evaluate products and match them to enterprise requirements. This white paper offers six separate issues for network and security architects to consider that are important to any enterprise-sized deployment of UTM.

The Trusted Computing Group (TCG) team is quickly getting their act together. Everyone wants to play with Cisco and Microsoft, the powerhouses of the NAC business, but the lure of open protocols and industry standards is a strong one. While TCG’s work on NAC is still incomplete and in-process compared to Cisco’s more mature framework, we had no problem in getting enthusiastic support in building a full TCG-based solution.

In some ways, TCG is at a substantial advantage. For example, we had two different TCG policy servers, including an open-source one, while Cisco is struggling with a patched-up policy server badly in need of a redesign and Microsoft won’t release Longhorn until next year.

Cisco has an amazingly broad solution and great industry support. When most people talk about NAC, they end up waving their hands when it comes to the details. Unfortunately, that’s not good enough for a complete and successful deployment. Having a framework is a nice thing, but having answers for all the details is critical. Cisco has those answers, either from their own portfolio or from a broad set of supporting partners.

Cisco’s extensive experience in the enterprise counts for a lot, and should not be underestimated. We were even able to use the Cisco Clean Access (CCA) solution as part of the TCG demonstration, to fill in gaps where the TCG architecture doesn’t reach.

Microsoft is marshalling its forces. For a product that won’t be shipping for at least 6 months, we had an astonishing number of people gathered around the Microsoft table trying to make the Vista/Longhorn-based NAC solution working. You can see the full picture in New York at Interop, but we had hardware from Aruba, Cisco, Enterasys, Extreme, HP, and Nortel in the picture, along with software from Lockdown, Trend, and Symantec.

This tells me that when Microsoft does release Longhorn, they’re going to be strong out of the gate with solutions and partners. Of course, my own hope is that Microsoft and Cisco and TCG can come together so that there’s a single solution, rather than three almost identical but just slightly different approaches. In the long run, that’s going to be better for everyone.

Six Integral Steps to Selecting the Right IPS for Your Network

Here’s the Executive Summary:

Network Intrusion Prevention Systems (IPS) can be extremely effective pieces of your overall network security strategy. However, the IPS marketplace is filled with products that all do very different things and are suitable for very different environments. Therefore, buyers beware, because simply throwing any IPS into the network without careful consideration can be a costly error, both in terms of capital outlay and operational provisions.

The critical question to answer is: “Why are you buying an IPS?” (Step 1) Answering this question will help define both what you want in an IPS and help you weigh what you can expect to get from these products as you evaluate them for use in your network.

With the answer to this underlying question in hand, you’ll be well positioned to closely examine four aspects of IPS products that distinguish them from each other:

• Security parameters and coverage (Step 2)
• Performance (Step 3)
• Form factor (Step 4)
• Management (Step 5)

Considering how each product delivers on these four characteristics will allow you to quickly and efficiently create a short list of products that you will need to evaluate and test in your own network (Step 6) as the final –and essential - part of assuring that you are achieving the goals that will justify the costs associated with deploying an IPS in your network.