<![CDATA[[SecurityRatty] tag: primer]]> http://securityratty.com/tag/primer Thu, 03 Apr 2008 01:31:59 +0000 iRatty Engine http://blogs.law.harvard.edu/tech/rss <![CDATA[A primer on the Exchange Server 2007 Exchange Management Shell]]> http://securityratty.com/article/848f13e4c62f5f6b7c54b8503abbff65 http://securityratty.com/article/848f13e4c62f5f6b7c54b8503abbff65 ]]> Wed, 02 Jul 2008 06:40:33 +0000 exchange management shell exchange server basic ems commands ems tutorial introduction wary A primer on the Exchange Server 2007 Exchange Management Shell <![CDATA[The 802.1X Hat-Trick]]> http://securityratty.com/article/09d9695144200f268c18e0c036eec36b http://securityratty.com/article/09d9695144200f268c18e0c036eec36b 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!

# # #

 

]]> Sun, 29 Jun 2008 22:39:27 +0000 customers government customers variety real world implementations wireless aps actual implementations wireless address issues The 802.1X Hat-Trick <![CDATA[Successful 802.1X Every Time]]> http://securityratty.com/article/31c561f94756b4a64cf6425397c85c5b http://securityratty.com/article/31c561f94756b4a64cf6425397c85c5b It’s not rocket science, but any time we mingle and intertwine four or five different pieces of technology, there’s always the potential for a mess… or at least a misconfiguration or two along the way. Don’t know what 802.1X is? Check out the recent 802.1X technology primer.

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!

# # #

 

]]> Fri, 20 Jun 2008 00:18:15 +0000 test radius radius radius log activity test radius client test client time radius server test switch Successful 802.1X Every Time <![CDATA[802.1X-REV: Ya' Heard it Here First!]]> http://securityratty.com/article/77082a74453cca4bb68ae0eadef5e8de http://securityratty.com/article/77082a74453cca4bb68ae0eadef5e8de Well, you’re not necessarily hearing it hear first, but it’s likely… unless you read IEEEdocs religiously (as I do) or read Paul Congdon’s standards updates at the ProCurve Networking site.

If you have no clue what 802.1X is, read my recent technology primer first. If you’re already familiar with 1X, you’ve probably heard about some of the 802.1X additions- the 802.1AE (MACSec) and possibly 802.1af (the key agreement for MACSec)… but that’s just the tip of the iceberg, and what’s hiding underneath will knock your socks off!

We’re currently at the 802.1X-2004 edition, with the group working on the REV and hoping for an early-2009 release. When IEEE makes additions (such as AE and af) they’re just afterthoughts and changes tacked on to the end of the standard. But when they do a revision , as they are now, they’re opening up the whole can of worms and all parts of the standard are opened for evaluation and modification. Yee-haw!

So, what’s in this new revision and what can we expect from 802.1X-REV? That’s what I wanted to know, and I’m sure you’re curious too. I was lucky enough to catch a quick call with Paul Condon earlier this week and get some of the inside scoop. Paul is ProCurve Networking’s CTO, but more importantly for our purposes today, he’s the Vice -Chair of the IEEE 802.1 working group and is intimately involved in 1X and a variety of other networking, security and authentication standards.

1) Encryption & Key Exchange : The first goal in updating 802.1X was to add security with encryption, specifically on switch-to-switch links. Of course, with encryption comes the need for fast, secure key exchange, so we ended up with 802.1AE and 802.1af as answers to the first set of goals. The encryption will require hardware refreshes, and vendors are already gearing up for that. The benefits of encryption are pretty obvious, so I won’t bore you with that. There are some fun little gems hidden in the AE/af set though. Even without using the encryption piece, we’ll be able to use the key exchange as a means of quickly (in ~4-5 packets) authenticating (or re-authenticating) switches to one another after a reboot. It will be a critical piece for maintaining availability and integrity in the network. And w e can do this piece without a hardware upgrade, which is pretty nifty.

2) Same-Port Multiuser Support: Here’s where the 1X-REV sauce starts tasting really good. The new revision is leveraging some of its security updates to support multi-user modes on a single port. And no, not by using multi-tagged VLANs, this is way cooler than that. In theory, multiple PCs, phones or other connected devices can connect through a single port, which would essentially be running multiple instances of 802.1X, letting each communicate securely. It’ll be similar in practice to how wireless APs segregate and encrypt traffic between the AP and the endpoint. I’m sure at first we’ll see software-based endpoint encryption support and of course, move towards hardware encryption and see NICs with the capability baked in. That’s still down the road, but the road is getting shorter.

3) Network Advertisement/Selection : Now the 1X-REV sauce is the best you’ve ever had- you’re gonna want to put this stuff on everything ! :) The 3rd goal of the revision is to add support for network advertisements on the wired side- which would be a similar experience to selecting the wireless SSID from a list of ones available on your laptop. But, it’s happening on your wired switch. Wild, right? They’re going to leverage the EAPOL types here to communicate from client to network. Imagine the possibilities…

All these new functions and features give 802.1X numerous new use cases. I think you’ll see parts of these technologies leveraged in various parts of critical networks everywhere. Sponsor ballots come at the end of the year, and they’re hoping to see something solid and released in early 2009.

You can see why I’m excited. The 802.1X-REV may be the evil stepchild for a while, but it’s coming. When it does, it’s going to rock our little network worlds and flip our thinking about wired security and network segregation upside down.

Of course, you’ll be seeing more on this from me, so hang in there!

# # #

]]> Fri, 09 May 2008 10:59:51 +0000 1x-rev 1x-rev sauce starts 1x-rev sauce support same-port multiuser support endpoint encryption support rev endpoint encryption 802.1X-REV: Ya' Heard it Here First! <![CDATA[The physical access control project planner]]> http://securityratty.com/article/08c4396c680e6509a54ce7f459108974 http://securityratty.com/article/08c4396c680e6509a54ce7f459108974 Tue, 29 Apr 2008 20:00:00 +0000 issues common issues frequently lead cost overruns saved time implementation unreliable system primer highlights fundamental information lost time The physical access control project planner <![CDATA[Keeping your Mac locked down: a Mac OS X security primer]]> http://securityratty.com/article/2093c16ff32ee73477c76780d6551b6c http://securityratty.com/article/2093c16ff32ee73477c76780d6551b6c Thu, 17 Apr 2008 22:30:01 +0000 mac security mac users common criteria guidelines apple developer site smartcard support website aspect Keeping your Mac locked down: a Mac OS X security primer <![CDATA[Microsoft SDL Process in detail]]> http://securityratty.com/article/24d4e4718f449664310a9dbbe27444a0 http://securityratty.com/article/24d4e4718f449664310a9dbbe27444a0

Hello all – Dave here…

I am currently at RSA and decided to take a few moments to blog about some updates to the Security Development Lifecycle.  Admittedly, I have been “radio silent” on the blog for awhile – for those that know me, that’s usually a warning signal that I am cooking something up…

Anyway, back when we first started this blog we promised that you would see more about the particulars of the SDL – and I think we have done a reasonably good job.  Michael Howard has written some pretty interesting pieces on a wide variety of subjects; bug post-mortems, philosophical notes and the like.  Adam Shostack did a fabulous job on the threat modeling series; Eric Bidstrup took a deeper look at the perceived vs. real benefits of the Common Criteria and I have penned a moderately well received screed or two from time to time.

However, one of the common requests (complaints?) that I have heard is that we have been short on the real “guts” of the SDL – that is to say, a point by point examination of how to apply the SDL. I would argue that Michael and Steve’s book on the SDL is a good primer on how to get started.  I think Jeremy Dallman added more momentum with his “Crawling toward SDL” post, giving some practical advice on how to approach the issue of secure software development from scratch.

Despite these efforts I have heard that people still want more detail – some folks are curious about how an organization the size of Microsoft programmatically drives culture change; others are looking for guidance that can be repurposed for their own organizations and finally, some folks are convinced that we are deliberately holding back some security “secret sauce” for some reason.  Go figure.

With that, let me cut to the chase.  Today, we have made the Microsoft Security Development Lifecycle, version 3.2 available for your perusal on MSDN.  This has been in the works for quite awhile and has involved a ton of folks in SEC and TWC putting in a lot of hours and resources into getting this published (props to Ziv Fass and Jed Pickel!).


As you can probably guess, this is not an exact duplication of the SDL for a number of reasons – but it’s pretty darn close. Given that caveat, allow me to illustrate a few points about this guidance...

 

  • First, we have gone through and removed Microsoft specific jargon, references to internal resources on our intranet, and things that would likely make zero sense to an audience outside of Microsoft (the scrub work was one of the primary inhibitors to publishing previous versions of the guidance).
  • Second, this is a generalized representation of how the SDL is applied at Microsoft for the development of rich client and server applications – while many of the principles apply to the creation of web applications, I would caution you to view this in the correct context.  While Bryan Sullivan has written about web development in the past we’ll have more on SDL and web application development in the future.
  • Third, for all intents and purposes the SDL is considered the “minimum bar” for security and privacy at Microsoft for those products with meaningful security risk; there are a number of teams that choose to invest more time and resources as necessary to meet product team goals that may exceed the SDL.  We salute that behavior.  : )

Finally, in reference to the third point above, I am compelled to say the following. (LEGAL DISCLAIMER ALERT – those with weak constitutions should avert their eyes):

 

The following documentation on the Microsoft Security Development Lifecycle, version 3.2 is for illustrative purposes only. This documentation is not an exhaustive reference on the SDL process as practiced at Microsoft. Additional assurance work may be performed by product teams (but not necessarily documented) at their discretion. As a result, this example should not be considered as the exact process that Microsoft follows to secure all products.

This documentation should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented herein. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, OR STATEMENTS ABOUT APPLICABILITY OR FITNESS OF PURPOSE FOR ANY ORGANIZATION ABOUT THE INFORMATION IN THIS DOCUMENT.

 

For the morbidly curious: Yes, I wrote that; yes, it passes legal muster; no, I am not a lawyer, nor do I play one on TV.  : )

So there you have it – Microsoft SDL 3.2.

There are a few sharp eyed souls that read the blog and will wonder about our publishing schedule for updates – it’s no secret that we examine the SDL every six months and either add new requirements to meet emerging threats or deprecate old guidance.  It has been described by some as analogous to “changing tires on a moving vehicle.”  Let me say now that we will NOT be publishing new SDL guidance on a six month schedule for the foreseeable future – we’ll settle on a reasonable publication frequency and hopefully accelerate over time.


I welcome your thoughts and comments...

 

]]> Wed, 09 Apr 2008 15:13:00 +0000 sdl microsoft sdl sdl process microsoft sdl guidance guidance secure secure software development development Microsoft SDL Process in detail <![CDATA[Microsoft patches critical bugs in Windows graphics system]]> http://securityratty.com/article/d8af806df99a8c6dbbb7363687177d9e http://securityratty.com/article/d8af806df99a8c6dbbb7363687177d9e

Register for a WAN Acceleration Technology Primer

Advertisement

This paper explores the differences between commonly used WAN acceleration technologies.

]]> Mon, 07 Apr 2008 20:00:00 +0000 wan acceleration technologies core graphics subsystem paper explores windows critical patch microsoft monthly security advertisement fixes Microsoft patches critical bugs in Windows graphics system <![CDATA[Laptop theft easily preventable while on the road]]> http://securityratty.com/article/83163464a049ada2a712bde7e7cac34f http://securityratty.com/article/83163464a049ada2a712bde7e7cac34f ]]> Sun, 06 Apr 2008 20:18:47 +0000 no-brainer security primer mobile devices theft road laptops employees hands common data Laptop theft easily preventable while on the road <![CDATA[This ain't no bloggin' booth babe!]]> http://securityratty.com/article/b4297fce7935f3a59f903504d5c0cc1f http://securityratty.com/article/b4297fce7935f3a59f903504d5c0cc1f Jen_2_bw_sm I was talking to an analyst the other day and the security bloggers network and meet up at RSA came up. In talking about it the analyst asked me if I knew anything about the "hot blond chick blogger that everyone was talking about". At first I didn't know who he was talking about, but soon I realized he meant Jennifer Jabbusch. After I stopped laughing for a while, I told the analyst that I actually found JJ's blog a while ago and had written about it and become friendly with her ever since. I told him that I met Jennifer in person a week or so ago, and believe me she may be blond, but she ain't no dummy and knows her stuff both technically and from a business perspective. After a while I thought about it and realized what a double edged sword woman like Jennifer. The fact that she is a woman and blond gets her attention easier than she might if she was just some guy, but is it the right attention? Do people assume that she is not somehow as sharp or as relevant? Two years ago I asked why the security industry had not outgrown booth babes. Today I ask why security bloggers are no better. Why do we assume because a woman who is blond and not frumpy looking must be some sort of booth babe blogger? I say bull crap to that. Maybe if Jennifer had not put her picture on her blog she would not be as popular, but would she be taken more seriously? People get with the program, JJ has a lot to say and let her words and intelligence stand on its own merit without your pre-conceived notions. Blogging has no room for booth babes!

On that note, Jennifer has a great post up today on a primer for 802.1x. I was presenting NAC to a group from a large security company this week and was frankly amazed at their lack of knowledge of what 802.1x is and how it works. They did not know where Radius ended and .1x began. I would have liked to send them this before presenting to go over as homework.

]]> Thu, 03 Apr 2008 01:31:59 +0000 jennifer jabbusch jennifer booth babes security bloggers network outgrown booth babes security bloggers people people assume assume This ain't no bloggin' booth babe!