I went to the salon today to ‘get my nails did’ and was greeted with quite a ruckus. The entire staff is Vietnamese- no big surprise there- but the owners and most employees speak English extremely well and so everyone is always chit-chatting throughout the salon.

The wife side of the husband-wife team was especially giddy as she shared a little gem of a story with me today… and I didn’t feel I’d be doing you justice to keep it to myself. 

They (the salon staff) all live in one of the larger cities here in NC. One of their friends (a middle-aged guy) was out shopping Monday and was sitting in his car in a parking lot during a coming- or going- to a store. A young girl (mid-20’s) came up to his car and motioned to ask for use of his cell phone.

Now, at this point in the story, I could have told you the rest…

He opened the window a bit and the young lady asked to borrow his phone for a moment to call a family member. Turns out she had some car troubles and needed a ride. Being the nice gentleman that he is, he lent her the phone and she took a couple of steps away to make the call. Only… she didn’t stop. Evidently she got about 4 cars down the row before our chivalrous guy got out of the car and gave chase.

When he got in reach, she pushed him down to the ground and - yep - ran back to his car, phone still in hand… and drove away.

He now has no car and no phone. So, ironically enough, he then had to approach a stranger and politely ask for the use of their cell to phone home and let the group know he was bamboozled. A few tears were shed, but his wife assured him it would be fine and he shouldn’t be scared. (No, I’m not making that up).

I was giggling right along with her (and the guy’s wife, who happened to be there).

Moments later I thought to myself, “I hope that doesn’t happen to me!” Almost in the same instant I realized… it probably wouldn’t. I’ve been a bit of a paranoid freak since I was little, thanks probably in most part to having two ex-military intelligence parents. For all my life I’ve been raised with ‘the security mindset’ as Schneier refers to it.

Always suspicious… always calculating… always aware… and certainly never underestimating a situation.

And so then I had to muse… WHAT WAS HE THINKING leaving the car running and unlocked to go after the siren with the cell? For the sake of politeness, I kept my question to my ‘inside voice’, but I do have to wonder why you’d sacrifice the security of a vehicle for a $50 cell phone.

The moral of the story…  There are two. 1) Involve someone with a ‘security mindset’ and 2) Your security is only as strong as your people. A sweet damsel in distress… social engineering at it’s finest…

# # #

Dear network vendor,

As someone that is forced to configure and implement security on your hardware, I would greatly appreciate stable code and properly functioning features. Unfortunately, I cannot always choose the hardware my customers are using in their infrastructure. However, if you would like for me to recommend they continue purchasing and using it, then the product must demonstrate to me that it is: capable, reliable, predictable and well-documented. If your product is not meeting these requirements, I’m forced to recommend other solutions to your (current) customer.

Stable Code. If I have to spend 2-6 hours per implementation working through your product’s bugs, and then must either spend time on a support call or spend time getting packet captures to prove to you it’s not working, I am not a happy camper because you’re slowing down my progress. Your customer is not happy because they’re paying for that time and I’m not cheap.

Features. Don’t publish in technical documentation that your product, or code can do something, only for me to find out later that it cannot. On-site in the middle of an implementation is not the time to architect Plan B. Let me know before, either through technical docs, white papers, best practices or release notes. I do read those. If you want to bend the truth, do it the marketing fluff, not my technical documents.

Documentation. If your product does do what you say it does, then please do document and explain the concepts and procedures. Examples are good, but explanations are mandatory. A correct CLI reference is always lovely as well. If there are got’chas or tricks, please also document those. Again, white papers or release notes are fine. Having to track down the one security engineer from your company that holds the magic key is not practical, nor scalable. Plus, he may be on vacation during my install, which would make me irate.

Support. If your product is not functioning or performing as expected, do NOT expect your customers to have a current maintenance contract to address a known issue or bug (or an un-known issue or bug for that matter). If they found a bug for you, you should probably give them a maintenance contract for a year… or two. If you don’t let us call support, I will find one of your pre-sales engineers and we will use him or her for post-sales support, which is not what you want them to do. But that’s your problem, not mine.

I believe that sums up the major issues. Specifically, I am interested in security, RADIUS, SSH, SNMP, DHCP and 802.1X functions. Before you add another bell or tweak another whistle, please make what you have works… consistently. That should be first, so it’s my Feature Request #1.

Respectfully,

jj

# # #

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.

# # #

For June, we have an 802.1X hat-trick to blame for my slack blogging habits. Over the past few weeks, I’ve had back-to-back 802.1X implementations, one wired, one wireless and one with both. Two government customers and one commercial, not in that order. And I even did one semi-training-slash-semi-implementation-quick-start for another customer.

It’s been fun, but 1X is always challenging. The variety of components, the nature of the interactions and the ‘newness’ of actual implementations make it difficult to work from any type of cookbook or implementation guide. There are just too many variables.

When will it be easier? I think as 1X is more widely implemented in the real world, customers will become more familiar with the concepts and integrators will have more experience to make it go smoothly. For now, everyone has to just take it one step at a time and address issues as they arise. And, for now, I’ll enjoy the job security that 1X offers ;)

Luckily, I’ve had the opportunity to work with a variety of customers and a variety of environments and equipment while hammering out 802.1X. The experience and exposure has certainly given me a unique insight into the issues, complications and solutions that come along with a 1X project.

At present, I think we’ve successfully configured 1X on about a dozen different types of equipment, both switches and wireless APs and controllers, from a variety of vendors. It may not sound like much, but in the world of 1X, that’s quite a variety when you consider each manufacturer has their own ‘system’ for configuring 1X and the commands and procedures can vary greatly even from product-to-product from the same vendor.

Is the 1X streak over? Not at all. We have several customers with NAC and 802.1X projects that we had to queue up for after June 30. I’ll keep you posted!

# # #

Of course, I was still trying to get work done at 10:30pm, but it was a nice 45-minute distraction from my dozens (or hundreds) of 802.1X technical pages.

You, too, can bask in the amusement that is Shimel and Ashley’s SSAATY Podcast and hear a few of my random thoughts and ramblings. I have a few more thoughts to throw on the Rohati pile probably, but we’ll get to that another day.

Below if from Alan’s blog post.

StillSecure, After all these years, #55 - JJ in the house

Episode 55 of SSAATY is a fun one.  Mitchell and I are joined by JJ, Jenifer Jabbusch of Security Uncorked blog.  JJ is someone I have gotten to know over the last year or so and she is a lot of fun. On top of that she is very technical and huge supporter of 802.1x, NAC and security in general.

JJ, Mitchell and I talk about Rohati, NAC, 802.1x and a bunch of other stuff in our usual rambling, stream of consciousness style.  It is about 40 minutes of informative good times.

If you like the content of these shows or have any other comments or questions, please drop us a line at podcast@stillsecure.com

Thanks to ClickCaster for hosting our podcast. Tonight’s music is the usual, To the Summit by Jon Schmidt. You can hear more from Jon at http://www.jonschmidt.com. Music transitions between segments are by our own Mitchell Ashley.

Listen online here:
http://www.clickcaster.com/channel/item/stillsecure—after-all-these-years—podcast-55-with-jj

# # #

If you’re planning to, or are implementing wired 802.1X, wireless security and/or NAC, the contents of this blog may save you hours of time and trouble.

Throughout the implementations I’ve done, for both wired and wireless 802.1X, I’ve developed a procedure for implementing and testing 802.1X each step of the way. Following these steps my seem to be tedious and unnecessarily time-consuming. But, if  you’re just starting with 802.1X, I’m offering a way to implement it in phased pieces that will give you the information to test, confirm and troubleshoot at each step.

To be honest, I frequently skip these steps, but I’ve done many 802.1X implementations and can usually hit the bullseye the first time (unless there’s buggy software or firmware- you guys know who you are). But, if something doesn’t work, I start right back at Number 1 here and I follow this procedure.

1) Configure wired 802.1X
First setup the basic wired 802.1X. Ideally, start with a Windows test, using XP SP3 or a later server edition and PEAP. Provision RADIUS, I recommend Microsoft IAS because it’s well-documented and well supported. Even if you have other future plans, if you’re using Active Directory, start with IAS. You’ll need to setup a test RADIUS group and policy and link to AD. Get a test switch, add it as a RADIUS client, and configure it to talk to your RADIUS. Set up some ports for 1X and enable it on the switch. I recommend testing with PEAP as the authentication method and a Windows credential pass-thru. Note- you’ll need to create a server certificate to use PEAP- a self-signed Microsoft cert is fine.

If this simple configuration doesn’t work, you have some troubleshooting options. First, view the system events log in the RADIUS/AD server and look for informational events from IAS. If the authentication request is making it from the client -> switch -> RADIUS, you’ll see something here. The something you see should tell you if the EAP method is mismatched, or if the credentials were wrong, etc. Your second line of troubleshooting comes if you don’t see any RADIUS log activity. If that happens, throw on a packet capture utility like Wireshark. You want to search for 2 things. First look for conversations from your Test Switch to the RADIUS server (filter on IP or MACs). If you see something here, see where the conversation drops off. If that comes up empty, it means the conversation is terminated between the Test Switch and Test Client. I have some neat tricks for troubleshooting I’ll share with you later.

2) Add in Wireless
If you’re planning to implement 802.1X for wireless, now is the time to throw 802.11 in the mix. It’s harder to sniff wireless traffic for troubleshooting, which is why I recommend starting with wired 1X. Keep it simple, and then start layering. Once you have the wired 1X configured, all you need to do is get your AP ready and configure it just as you did your switch- add it as a RADIUS client and configure it to talk to RADIUS. For wireless, you’ll need to configure encryption also. Note, I recommend (for testing) to begin with your primary VLAN.

If your wireless 802.1X isn’t working, follow our troubleshooting above and re-check settings based on the RADIUS event log contents. If nothing is making it to RADIUS, then most likely something is misconfigured in your AP/Controller and the AP isn’t communicating with the RADIUS server. You know the rest of it’s working (RADIUS, AD, Client) so you can narrow your troubleshooting scope. Once that’s working you can stop if wireless is your goal, or keep going if you’re layering on more security.

3) Replace with Custom Pieces
If you’re planning to use a different RADIUS server or a different supplicant, now would be a good time to start swapping out our vanilla configuration with custom pieces. Replace 1 piece at a time and re-test.

4) Add in NAC or Endpoint Integrity
Most NAC or EI solutions will integrate with your 802.1X infrastructure (if you want them to) and can be ‘consulted’ prior to authenticating and opening the secured port. My suggestion is to always get 1X working 100% before you add any type of integrity or compliance testing.

If you follow these steps, you can turn a complex configuration into a set of simple baby-steps. It may sound stupid, but I promise it’ll work for you every time!

# # #

When my renewal options appeared, there was a selection to upgrade to the shiny new Norton 360. Woo hoo! It listed all these great new security features… I don’t remember what they were… but, they sounded REALLY great (I promise).

So I went with the upgrade, instead of the anti-virus signature renewal. Okay.

It did seem like a good idea at the time. However, in addition to my overly-protective Vista popups eeeevvvvery time I want to run something, connect somewhere, or wipe my nose… Now, I have the Vista pop up AND the Norton 360 popup. Okay.

Except, the Norton pops up with flagrantly ambiguous information like “An application is trying to access your Internet.” Do I want to allow it? I don’t know. How am I supposed to know- which application wants to access my Internet? Oh, it’s not going to tell me. Okay.

Well, I guess I’ll click ‘Allow’ because I have no clue what is trying to access my Internet, but I’ll assume it’s something that I have somehow asked to access my Internet… and I’ll be quite upset if whatever I clicked on doesn’t work. So YES, ALLOW. Okay again.

And what was the point in that? One click has transformed to three, and I’m no more secure than I was before, I’m just being forced to make more clicks to earn my insecurity. So today I am the poster child of what NOT to do.

Security circumvented is quite possibly worse than no security at all. I see visions of ‘invalid browser certificate’ notices dancing in my head.

# # #

Stiennon talks about Rohati and their ‘new’ approach to NAC in the form of their NBEC, Network-based Entitlement Control. I, unlike some bloggers in our network, decided to check it out before formulating an opinion.

So, I checked it out and I’m a little disappointed… on several fronts. First, all the information I have with which to draw a conclusion is limited to the online ‘product demo’ available on their website. It’s not really a product demo, hence disappointment number 1.

Let down number 2 comes in the realization that the features they’re touting in the ‘product demo’ are actually things we can do today, with traditional hardware-based NAC solutions from those daily house-hold names… Symantec, StillSecure, Juniper, ProCurve, Enterasys and even Cisco. Rohati does (potentially) have a unique statement of being able to enforce policies without touching the client. But, again, we ‘can’ do that with several of the products I just mentioned. And I’m wondering how we could create the tunnel-like enforcement and security Rohati claims to offer without some type of agent on the client… after all, any encryption tunnel has to have endpoints, right?

I attempted what I usually do when I’m checking out security solutions, I went to the support section of the website to download product manuals or configuration and implementation guides. Even some white papers. I wanted to see how they’re really going about it all. But, disappointment number 3 jumped up and got me when I saw that the only resource on their support page was an email address. Hmm….

The company seems to be comprised mostly of long-term ex-Cisco employees. Out of the 8 members of the management team, there’s 1 President, 6 VPs and a director- 5 of which are co-founders. With just 2 years under their belt, I’m wondering what all they can have up their sleeve past a slight variation of current NAC solutions.

I may be completely wrong about the company and product(s). If I am, I’m sure someone will offer to send over some product manuals for me to read through…

The bottom line is… a rose by any other name would smell as sweet… or stink as bad.

# # #

It’s a huge undertaking with 10 domains chock full of every security topic you can imagine, 20 contributing SMEs from all over the worls, a handful of editors and 1 man to bring it all together. Our team leader, Dean Bushmiller has been the Project Manager for both versions 8 and 9 of the CISSP courseware and does an amazing job.

Each of the SMEs and editors have put a lot of thought and time into the materials, in an effort to create the best and most relevant content, topic arrangement and flow possible. You’ve seen how big these books are- that’s a lotta’ stuff to pull together and I admire the group, especially the domain wranglers and Dean, for keeping it all on track.

It’s a strange and exciting project. I can’t say it’s completely foreign to me, many years ago I created content for advanced Microsoft Office courses and developed official Computer Competency Training for K-12s for use in schools here. However, a project with this much mass is definitely unique.

So, that’s another little project I’ve been working on for the past several months… and will be continuing for several more. On those occasions I drop off the face of Blog World, it’s sometimes because I’m using every free moment to try and keep up with these types of projects and deadlines.

# # #

We may not… but after extensive Google searches, all I’ve been able to find are white papers, implementation guides and some classroom training on wireless security with mention of 802.1X.

I’ve done a *lot* of presentations over the past couple of years on 802.1X and related technologies, including a half-day technology review workshop. After some customer and integrator interest, I’ve turned the half-day training into an outline and materials for a 2-3 day full 802.1X immersion course.

The basic syllabus includes the technology overview, history, exploration of 802.1X components, a delve into selection criteria and interoperability and sections on the use of 802.1X in NAC and 802.1X in Wireless. Optional sections are available, such as the ‘EAP Dissection’ for those packet pinchers that want to ‘see’ it all. The syllabus can also be custom-configured to include vendor-specific training and even hands-on labs.

Is this the first true 802.1X training? Who knows… but we’ll see how it goes!

Training is scheduled and provided through Carolina Advanced Digital (CAD).

# # #