Security Uncorked

Well, it didn’t happen to me- but here’s another J! True Security Story for you…

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…

# # #

         I have a note to all network hardware vendors…

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

# # #

Yes, you read it right- Symantec (as in the software vendor) has a network-based (as in the hardware) NAC. Once you get over the title, keep reading.

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.

# # #

Well my recent blogging, or lack there of, may have clued you in on my recent hectic travel schedule. It’s June, and that means the end of government’s fiscal year, so we’ve been busy little bees at the office. (Read my primer on 802.1X here.)

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!

# # #

I guess Alan was bored, or couldn’t find a guest for last night’s podcast, so he grabbed me ;)

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

# # #