Boingo releases Mac client for its aggregated service: The free GoBoingo for Mac client works with Leopard, at last. Boingo resells U.S. and worldwide service at $22 and $40 per month, respectively, for unlimited use.

If you read my blog, or know me, you probably know I do NOT like software (and it usually doesn’t like me). So, I’d be the first to jump on the ‘anti-software-peer-based-NAC’ train, but I think we have to be informed before we jump to conclusions and hop on any trains.

Mirage’s recent blog post on Symantec’s ‘Silly SNAC’ was certainly a result of a mis- (or un-) informed person. Tim did a much better job on his mention of SNAC in the NWW blog, but all the dots still aren’t connected. It proves the point that sometimes we (as bloggers) tend to write based on a feeling and sometimes don’t dig for the fact.

So, in an effort to make sure I understood this new peer-based NAC, I reached out to Patrick Wheeler, Symantec’s Senior Product Manager for Network and Endpoint Security. Based on my conversations with him, and a pretty detailed investigation into the options and configurations of their NAC products, I have some slightly more informed opinion to share with you now.

Symantec has a variety of NAC enforcement components and options. I’m going to keep all the software-type-stuff out of this conversation for the time being. They have (among other things) the NAC Enforcer, an appliance similar to the other NAC controllers we see from traditional hardware vendors. Just like it’s counterparts, Symantec’s NAC Enforcer can be configured for DHCP, inline or 802.1X based enforcement.

The piece that’s different is the integration of the NAC Enforcer with Symantec’s Endpoint Protection Manager server that hosts the policies for the NAC. It’s similar to the management-enforcement configuration we see from other vendors, only the management piece is housed on a server instead of another appliance.

And, just as other vendors offer some type of endpoint integrity agent, the Symantec agent comes in the form of the Symantec NAC Client, which can be used by itself, or integrated with the Symantec Endpoint Protection Client for an even more robust feature-set. (The Endpoint Protection Client offers some additional host-based firewall features that the NAC can leverage).

So, what about the Peer-Based NAC? Ah, well that’s just the first iteration of a ‘vision’ to address mobile corporate users. If employees have laptops in an ad-hoc situation outside of the enterprise infrastructure (and therefore, outside of enterprise enforcement), then the peer-based NAC can port the enforcement rules set at the ‘mothership’ and enforce them individually. The peer-based NAC can protect mobile assets in their most vulnerable situation, outside the security of the corporate network. But, the rules are still set centrally and the peer-based NAC was designed to be just one step towards an added layer of protection, not as a replacement for network-based NAC.

For now, I’ll stay off the hate train, since the peer-based NAC is more of a supplement to a more robust traditional NAC solution. If they move to a fully-host-enforced product, I’ll buy my tickets…

Image shown is copyright of Symantec Corporation.

# # #

At TechEd this year, I gave a presentation called "21st century networking: time to throw away your medieval gateways." (Actually, I've given this same talk before, at events in Amsterdam, Brussels, Oslo, and numerous on-campus customer meetings. It's time to bring the knowledge to the masses.)

I described an idea of using IPv6, IPsec, NAP, and group policy to build a pretty slick replacement for clunky VPN gateways. Turns out we've been piloting this very idea on our internal corpnet. Like a good little bunny I got myself enrolled in the thing and -- pardon the unattractive gushing -- this thing rawks! Here's a brief rundown of the parts you'd configure on managed clients:

• Windows Vista Business (with Software Assurance), Enterprise, or Ultimate editions
• That are domain-joined
• Users run as non-admin
• Group policy applies numerous settings
• UAC is enabled
• BitLocker is configured to protect confidential information stored offline
• The Windows Firewall is enabled
• NAP is used for checking health
• Forefront Client Security for keeping malware off the box
• Smart cards for strong authentication of users
• IPsec is required for connection authentication and traffic encryption
• IPv6 is required for worldwide Internet connectivity
• A DNS suffix search list represents the data center name space
• Static IPv6 DNS servers provide name resolution for hosts in the data center

What does this give you? True anywhere access, anywhere in the world, directly to corpnet resources from managed and secure client PCs. The Internet has replaced private WAN links for good reason: enormous cost benefits. The only thing holding us back from fully utilizing this development has been a lack of way to enforce and monitor the security of clients not physically located within the corpnet. Well, those days are over. Now you can build PCs that are trusted just as if they were on the corpnet, without knowing or caring anything about the underlying network connections. And let me tell you, it's as addictive as a few other substances I could mention, but will refrain, since this is (I hope) a family blog :)

Maybe you've heard of the notion of "deperimeterization." Taken to its extreme, I think it's a bit silly. To put a SQL Server directly on the Internet is just plain stupid -- not because I don't think I could keep it protected, but simply because that's unnecessary risk. Only my web server -- and no one else -- should be talking to my SQL Server. But that web server will be in the same subnet as the SQL Server, and IPsec policies used also here will govern who can connect to the SQL Server. Warning to any and all network DMZs: your days are numbered!

Shrink your perimeter to that which really matters -- your data center. All your clients live (as we would say in the olden days) "on the outside of the firewall." Now then, there are two kinds of clients. Managed clients, as I described above, establish IPsec-authenticated/encrypted, group-policy-configured, NAP-enforced IPv6 connections directly to corpnet resources without going through any kind of access gateway. The router connecting you to your ISP is fully sufficient for blocking denial of service attempts. Be sure to follow my advice in "Configure your router to block DOS attempts," and then add two more rules to permit incoming port udp/500 and IP protocol 50 over IPv6. That's it. No NATing or other unnatural network acts are required (finally, you can stop lying to your significant other about why you squirrel yourself away in the computer room all those weekend nights).

Unmanaged clients will continue to use IPv4 to access published Web and Win32 applications through a gateway like IAG. Since you can't trust these clients nor can you trust the data they're throwing at you, you have to inspect and validate at the perimeter. You can take advantage of IAG's application-modifying capabilities to "wrap" security around poorly-written web apps; you can even download an ActiveX control to unmanaged clients to perform some basic health checking, policy enforcement, and cache clearing. None of these eliminates the final requirement to continue inspecting and removing malware from servers where users store data: Exchange, SharePoint, Office Communications Server, and file servers.

Machines are mobile, data is mobile. The mainframes and large desktop PCs of the past posses an effective security attribute: the heaviness of the machines. You couldn't easily saunter out the front door with a PC-AT in your pocket! These days, we all line our pockets with tiny little mobile phones stuffed with 16GB of storage. It's now a fact: data moves. And like water, data moves wherever it can, as rapidly as it can, often beyond your control if you don't prepare for that. With properly-configured and managed clients we can enjoy a single access and authentication experience no matter where the computer is physically located. For example: I can sit in my house and enter '"http://internal-web-site-name" in my browser. The DNS suffix search list adds the appropriate suffix, my browser's resolver performs an IPv6 name lookup, and my computer makes an authenticated and encrypted connection, after it meets the NAP policy, directly to that internal server. Very nice. As far as I'm concerned, there's no difference between the Internet and my corpnet. It's all just there.

For a while now many of you know I've been speaking and writing, mostly at the conceptual level, about the day when such a way of remote computing will arise. Well, my friends, that day is now. You can indeed build it now, with the products you have. I won't admit it's all peaches and cream: there's a fair number of moving parts here, it's true. But most of these moving parts are parts you're already familiar with: I'm simply encouraging you to move them in a specific way. You'll need to do some custom scripting for client-side connection diagnostics, but that's about it.

My next step is to create a more detailed guide, which I plan to publish through TechNet Magazine. I'm targeting (but not promising) the October issue. The article will include greater details about configuring your infrastructure to support the managed clients I describe.

I've lost track of the swelling number of individual conference attendees and the plethora of email writers who've expressed a desire to build this in their own environments. The one common thread from everyone is "I want to do it now!" Folks, it's really pretty exciting for me to see so many of you ready to cross the chasm from the perdition of paleo-networking (layer upon endless, complex layer of DMZs) into the paradise of flat, simple, cheap, and secure access to information. If you haven't yet, please take the time to read through some of our information (especially Scott Charney's paper) on end-to-end trust. Friends, the idea I describe above is the plumbing for realizing the end-to-end trust vision.

Next, insert appropriate morbid jokes <here> for "IDS is dead", "NAC is dead", "GRC is dead", everybody is dead... WTF? Are we at the cemetery or what? Is "dead" dead? Yeah, but it came back as a zombie :-) So, "dead" is a "living dead" "dead" now. Ha*3.

Finally, think! Why were you thinking of buying a SIEM? 'Cause the big "G" in the sky said so? And while you are thinking, check these fun points out:

1. Does your SIEM require 17 beefy servers to operate? How many gallons of foreign oil have to go up in smoke to power that mammoth up? And you know what happened to mammoths, don't you?
2. If your "high-performance" SIEM appliance can only run 5 correlation rules at the same time, what "high" do they mean, really? Hold this thought....
3. Is five field engineers, two developers and CTO enough to install it? Who else needs to help? Ah, sorry, I missed the DBA :-)
4. Do you know when "If CustomVariable17 = Value5" condition matches? Will you still remember it in a year?
5. Can you tell "taxonomy" from "ontology"? You can now? Good for you. Are you more secure now? More efficient? Compliant?
6. How many shifts of security analysts do you have watching the shiny consoles 24/7? If zero, then why - oh - why those consoles are running in the first place? "If a tree falls..." - you know how this one ends. Correct! You get hit by the bough.
7. When was the last time you built a custom agent for parsing and normalizing, say, SAP logs? Did it work? What did you do after it didn't? Cried? And did it help? Then a burly vendor SE showed up, charged you $37,600 and left? Happy now?
8. Do you automatically correlate IDS/IPS alerts with vulnerability data ... for client-side attacks? Really? :-)
9. There are dozens of firewall, IDS/IPS, router, etc brands, each with its own log type. This is actually simple! But there are thousands upon thousands of applications in use today. Some have logs. All are different. Care to build rules for that? Now you finally know why SIEM vendors don't parse their own Java logs (no shit!)
10. Do you know what "threat x vulnerability x random()" equals to? Yup, it still equals random(). Automated prioritization, you say?
11. Do you know why some SIEM vendors are migrating to IT GRC now? So they can go and die there ... quietly.

All in all, I have to agree with Raffy to a large extent!  The world has evolved - and SIEM has not. It might not be dead (as old attacks and defenses never really die and large organization still build and man massive SOCs where SIEM is "a must"), but in this age of web application hacking, CSRF and XSS, phishing, PCI DSS, massive bot armies, client-side 0-days, stealth malware, etc, paying $x,000,000 for a pile of ugly Java code is insane ... As a result, SIEM has greatly diminished in importance and has become just one small thing you might do with logs and some other data. What made it so? Mostly implementation complexity - but a slew of other factors mentioned above as well.

So, consider this instead:

• Compliance? "Sorry, buddy, you need this for compliance, not that. "
• Want to simplify your incident response? Get log management and fly through all your logs, not crawl through some of them.
• Have a very real need to dig into your logs for troubleshooting or tracking that pesky user? Log management works.

Now, what if you have a latent and vague desire to "correlate something" and a million nice greenbacks to flush down the drain? OK, go get your SIEM toy for $780,000 + 20% maintenance/year ... a true bargain (price valid today only).

Finally, I would like to end this on an optimistic note. Do we need more intelligence to analyze the log data we have collected? Of course! Do we have a widest set of log use cases from today's security  to tomorrow's regulations? You bet. And, for you Raffy, I'd add "... we also have other data to analyze together with logs." So, can we "reinvent SIEM?" Yes, I think so! It just hasn't been done yet ... For now, just use log management.