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!

# # #

Have you ever sat in a corporate training? Some are good, some are bad, but did you ever say, “man I can’t wait for training today.” What about mandatory training? What about mandatory training in a subject that you really don’t think is your area? What if you had to do it every year, and got harassed if you didn’t do it? What if you were, say, an audio engineer and were dragged into a security class?

I ran the SDL training program at Microsoft for a long time, and developed and taught a big chunk of the training. I spent hundreds of hours in front of thousands of developers, testers, and program managers. I got some really good reviews (and a few bad ones) on the classes I offered. And I tried to do a lot of things to try to make the trainings interesting. I handed out dozens of fresh peaches in an early class on fuzz testing, for example.  The room smelled really nice after that, and there are probably still a few people around Microsoft who think of fuzz testing when they see a peach.

But even on my best day, I was under no illusion that the majority of the audience was excited to be there, and I was certain that they weren’t going to go back to their offices and spend weeks applying the lessons from the class, setting aside other things that are causing present and immediate problems in favor of something that is far off into the future.

You have to work at getting people’s attention – especially as it relates to security and privacy. From time to time, I would see people reading their mail in class, and I would point to them and ask them a question. That did not endear me to the audience as much as the peaches, but embarrassment is always fresh and in season.  J

One student wrote of one of my classes, “the basics for secure design - could be replaced by non-anonymous site-wide exam with open material.”  He was not alone, I assure you.

Is that an indication that our training, or any training, is pointless? Hardly, but training alone is not a change agent.

Richard Derwent Cooke wrote,   “It is a first principle of Change Management that people will act in what they perceive as being their best interests.”

At best, training can provide people with insight into what they need to do to solve a security problem if they believe that solving that security problem is in their best interests.

To be effective, training needs to happen in an environment:

·         Where expectations are clearly set (the SDL sets specific minimum requirements).

·         People have appropriate incentives and consequences (security is a great career path at Microsoft, and nobody wants to be the one holding up a ship schedule for failure to meet a security requirement).

·         Where tools and resources to accomplish the goals are available (we build a whole variety of tools that map to the SDL requirements).

·         Where management models the behavior (recall the original BillG TWC memo).

·         Where the environment reflects and supports the values presented in the training (apparent in everything Microsoft does).

Don’t make the mistake of thinking that a bunch of training, even really high quality training done periodically, will result in actual behavior change. It won’t. You have to build an environment where people perceive solving security problems as being in their best interests. You have to make security their problem – not in the sense of passing the buck, but in the sense of changing their behavior so they will bring security problems to you.

To illustrate further, I’ll cite two examples. First, fuzz testing. Fuzz testing has been a success story here at Microsoft. Tools arise spontaneously to solve new fuzzing challenges, written by people who believe the challenges are their challenges. There are people who feel ownership for our fuzzing strategy and on-going research and science, there are specific goals and requirements, we have training (remember the peaches?), and internally developed fuzzers have won prestigious awards within the company, handed out by members of the executive staff, and all of this gets revisited periodically as part of the SDL.

 By contrast, I’ll choose a less successful area – defect estimation. On my own volition, I created (based mostly on some excellent material from Microsoft Research) and taught a class called “Defect Estimation and Management” and added it to the SDL curriculum. Microsoft is a great place to work in that regard. It was pretty close to the best-reviewed class I taught. But, we have not yet been able to establish a set of tools to estimate security defect density effectively, and establish a fair set of expectations, incentives, and consequences, or even  decide what we should do if we had the data. We discovered some things, though. For example, based on what I observed (which should not be construed as rigorous research), it does not appear as if the density of general defects correlates closely with the density of security defects.  And Microsoft Research found higher code coverage in testing correlates with higher bug rates in the field.

And so even though people like the idea of defect estimation, and we’ve got some interesting and surprising data, we’ve not yet been successful in changing people’s behavior.  Generally speaking, an individual test manager does not feel that establishing a high quality estimate of their defect density is in his or her best interests, as compared to, say, improving the time in which an established series of tests can be performed .  

We need to build an environment that has the tools, training, rewards and incentives, and expectations and consequences to change people’s behavior. Not that we’re not trying. But training won’t solve it alone, nor would tools, trophies, rants, testing, code review, or some edict from on high. The SDL is as much about changing the culture and influencing the behavior of individual engineers as it is anything else.

I’m convinced that Microsoft’s SDL process works because it addresses the end-to-end problem - from training through servicing, and provides a complete environment where people feel ownership of their part of the security problem and have the resources to solve it.

So the next time you find yourself sitting in some mandatory training, remember the lessons of the SDL (and most of the research on human performance management): training alone won’t cut it. If you want real behavior change, there have to be things outside the lecture room to influence people to change their behavior.

This one was far more serious. As soon as I heard the smash and saw the impact out of the corner of my eye, I pulled into the median, hit my hazard lights, and called 9-1-1. One of the advantages of working in the field for so long is that you learn an economy of words to describe a complex situation in just a sentence or two of the crucial information. My first call was:

I’m on-scene of an injury accident at the corner of [x and y]. Two vehicles, with an unconscious unresponsive patient with a compromised airway. Patient is entrapped in the passenger side of the vehicle with access through the driver’s side door. I’m a former paramedic and need to go manage her airway

There was a bit more jargon, but not much. The patient was unrestrained in the car with the airbag deployed, which probably meant she hit her head on passenger window or strut since it was a side impact. There were a bunch of other bystanders and one came out and identified himself as a flight nurse. Her head was slumped over, which caused her difficulty breathing. The nurse jumped in the back of the car, we tilted her head to a normal position and stabilized her neck (one of the few times you’re allowed to move the neck after an accident). Her breathing got better, and she slowly started waking up, but clearly had a head injury, which we reported to 9-1-1. The fire department showed up a few minutes later, we got out of the way, and she was being loaded into the chopper as I drove off.

That might be one of the only times I’ve stopped to help at an accident where my assistance may have mattered. Truth is, unless you’re on the ambulance or have advanced equipment with you, the most useful thing you can do is calm the patient and make sure there isn’t any more damage. The kinds of injuries you sustain in a major accident are rarely something even a highly trained bystander can help with. I didn’t even bother evaluating anything more than her breathing, since nothing else mattered. All you EMTs can skip that full survey if you’re helping as a bystander in an urban area.

In this case her head position was keeping her from breathing well, making the situation worse. Just moving it so she could breathe more normally might have oxygenated her noggin a bit more and helped her wake up. ‘

Why the heck am I talking about this on a security geek blog?

Because it’s one of those times where there are direct lessons we can apply to our world, and often forget.

I’m a big fan of Rothman’s philosophy of REACT FASTER. The idea is that it’s more about how you respond to an incident than having the incident in the first place. Truth is in IT, as in life, bad stuff will happen no matter what you do. Systems will crash, hard drives will die, and hackers will break in. David Mortman is one of the other major proponents of this philosophy- incident response is just as important, if not more important, than incident prevention. That’s why I’m adding REACT BETTER.

Emergency services is just like programming- a series of algorithms in a structured program flow. It all comes down to the A B Cs- Airway, Breathing, Circulation in meat-space. Patient have any airway? Nope? Then nothing else matters until you fix that. Breathing? Check. Circulation okay? Then move onto spinal immobilization. It’s a recognition that you can’t jump from A to C and expect success. It’s exactly what we did to help that girl in the car, rather than focusing on the blood or other distractions.

Don’t just react- have a response plan with specific steps you don’t jump over until they’re complete. Take the most critical thing first, fix it, move to the next, and so on until you’re done. Evaluation, prioritize, contain, fix, and clean. (You OODA fans should love this).

And always remember the loudest patient is rarely the most important. If they’re screaming their head off, their airway is fine. It’s the quiet ones you have to watch out for.

One of the cardinal rules of computer programming is to never trust your input. This holds especially true when your input comes from users, and even more so when it comes from the anonymous, general public. Apparently, the developers at Oklahoma’s Department of Corrections slept through that day in computer science class, and even managed to skip all of Common Sense 101. You see, not only did they trust anonymous user input on their public-facing website, but they blindly executed it and displayed whatever came back.

The result of this negligently bad coding has some rather serious consequences: the names, addresses, and social security numbers of tens of thousands of Oklahoma residents were made available to the general public for a period of at least three years. Up until yesterday, April 13 2008, anyone with a web browser and the knowledge from Chapter One of SQL For Dummies could have easily accessed ­ and possibly, changed ­ any data within the DOC’s databases. It took me all of a minute to figure out how to download 10,597 records ­ SSNs and all ­ from their website.

The truth is I agree with Mike that the days of hot have long cooled. We’re very much an industry now, and if I see something creative it’s often so engineering driven as to be doomed to failure (sorry guys, CLIs don’t cut it anymore). Since Mike was kind enough to post his themes, I’ll be kind enough to post my opinions of them and my own predictions. This is pretty negative until the end, mostly because we’re talking macro trends, not the individual innovation and maturation that really advance the industry.

(Warning, I use really bad words and uglier metaphors; if you don’t like being offended, skip this one. It’s a Friday, and this isn’t my most professional post).

Virtualization Security
This is the one theme I can’t argue with. We’ll see a TON of marketing around virtualization, and nearly no products that actually provide any security. Virtualization is *hot* even if security isn’t, and what we’ll see is the marketing land grab as everyone sprays marketing piss everywhere to cock block the competition.

GRC
I really hope Mike is wrong that GRC will be a big theme. If he’s right, I’ll be spewing vomit all over the show floor before I even start bingeing. GRC is nothing more than a pathetic attempt by technology vendors to ass-kiss their way into an elevator pitch to executives who don’t give a rat’s ass about technology. GRC tools are little more than pretty dashboards that don’t actually help anyone get their jobs done on a day to day basis. Every CEO/CFO loves them when they see them, but there is no person in the organization with operational responsibility to use them on a day to day basis. Thus there is practically no market; and what few companies buy these things don’t end up using them except for quarterly reports. On top of that, the vendors charge way too much for this crap.

On the other end, we have useful security management and reporting tools that get branded GRC. This isn’t lipstick on a pig, it’s smearing crap on a supermodel. Some people are into it, but they are seriously wacked in the head. These tools still have value, but you might have to dig past the marketing BS to get there. The more “GRC” they pile on, the harder it will be to find the useful bits and get your job done. Here’s a hint folks- people have jobs; give them tools that directly help them operationally get their job done on a day to day basis. If it craps pretty reports for the auditors, so much the better.

Security in the cloud
I’m going to split this one a bit. On the one side is true in-the-cloud security; ISPs and other providers filtering before things hit you. It’s very useful, but I don’t think we’ll see it as a big trend.

The next big trend is services in general, but I don’t consider these in the cloud. Services are a great way to gouge clients (as a consultant I should know) and more and more vendors want in on the action. Everyone’s tired of IBM having all the client-reaping fun. Security services in general will definitely be a top 5 trend. It’s not all bad- there are a lot of really good services emerging, but it’s a buyer-beware market and you really need to do your research and make sure you have outs if it isn’t working.

And now a few of my trend predictions…

Data leakage that isn’t DLP
Everyone here knows I’m a fan of DLP; what I’m not a fan of us random garbage calling itself because it prevents “data leaks”. I blame Nick Selby for this one since he’s been lumping a bunch of things together under Anti Data Leakage. Yes, your firewall stops data leaks if you turn all the ports off, but that isn’t DLP.

This year will be the year of abuse for the term DLP, but hopefully we can move the discussion forward to information-centric security where many of these non-DLP tools will provide value. Once someone else buys them and stuffs them in a suite that is.

Network performance you don’t need
Remember, vendors are like politicians and lie to us because we want them to. You probably don’t need 10 gig network performance, but you’re going to ask for it, and someone is going to tell you you’re getting it. Even when you’re not, but you’ll never notice anyway.

The Laundry List
Stealing from Mike, here are a few other trends we’ll see:

Anti-botnets.
Anti-malware we thought our AV vendors were already doing.
Encryption integrated with other information-centric tools (this one is good).
Encryption integrated with random crap on the endpoint that has nothing to do with encryption.
All things with 2.0 in the name.

I’m a bit cynical here, but that’s because RSA is more about marketing than anything else. In every one of these categories there are good products, but RSA isn’t the place to be an honest vendor and have your ass handed to you by your competition. There will definitely be some really great stuff, probably some of it new, but the major trends are always about jumping on the bandwagon (that’s why they’re trends).

From a coverage standpoint I’ll be doing my best to give you a feel for RSA, minus the hangovers. I don’t get to attend many sessions, including the keynotes, but the news sites do a good job of covering those (besides, they’re nothing more than $100,000 marketing pitches). Martin and I will be interviewing and podcasting from the event and posting everything in short segments up on NetSecPodcast.com.

Since my shoulder won’t let me lug my laptop around, I’ll be using the iPhone (when there’s coverage) and posts may be pretty darn short.

See you at the parties…

One thing I noticed during our discussion of my section on the Information-Centric Security Lifecycle is that we’ve failed to talk about data governance. Since, thanks to Chris, I’ve been convinced that information is data with value, we’ll skip data governance and jump right to information governance.

Consistent with my last short post, here are a few points on principles for information governance:

1. The business, not IT or security, must determine the relative value of information.
2. Information classification must represent the value of the information.
3. Business and technical policies and controls must align with the information value/classification.
4. Information governance must be consistent, practical, and auditable.
5. The Board of Directors and Executives are responsible and accountable for information governance, which is then implemented by business units (including IT).
6. Information governance should not be so detailed it can’t account for new information, nor accurately reflect the reality of a business in motion.

These aren’t quite as thought out as the Principles of Information Centric Security, but I think they are a fairly reasonable place to start the discussion. Also keep in mind, that I’m not talking about in-depth, impractical classification of every piece of data in an organization. We’re talking broad strokes that are used to guide users in understanding what information has value over other information, and how that information should then be handled.

You’ll also notice I didn’t mention security. Not once. Security is only one tool in the governance kit.

Technorati Tags: Data security, Governance, Information Governance, Information-centric security, Information Security

I noticed the same phenomena occurring a number of times and then realized that people were using timing attacks to get free rides on the train.

The attack works as follows:

1. The train arrives at the station
2. The attacker boards the train and immediately enters the nearest railroad car bathroom
3. The train leaves the station
4. The conductor walks from car to car taking the tickets of the just boarded passengers
5. The attacker waits until the conductor passes bathroom and begins to collects tickets in the adjoining car
6. The attacker exists the bathroom and walks into the adjoining car in the opposite direction from the path of the conductor

This attack is normally good for only one or two stops because each time the train leaves a station, the conductor usually walks though their assigned cars taking the tickets of the new passengers.

Doing a cost/benefit analysis, certain solutions should immediately be ruled out since an extremely high percentage of people purchase tickets and do not hide in the bathroom:

1. hire a conductor for every car or
2. restructure each platform to prevent passengers from boarding the train platform without having already purchased a ticket

A much simpler way to help partially mitigate this issue without much cost overhead would be:

Have each conductor sweep their cars a second time after they are finished punching the tickets.

On the second round, if the conductor notices the bathroom light is still on, continue sweeping the remaining cars and then return to the car with the bathroom. The conductor waits in the car with the bathroom until the upcoming stop. When the person leaves the bathroom, check the ticket (for a legitimate fare), have the person purchase a new ticket (if they were trying to skip) or have them arrested if they are skipping the fare and refuse to purchase a ticket. If they notice the bathroom is empty upon their return, finish sweeping the cars a third time.

The major drawback to this issue is time between stations. It may take longer to sweep than travel from one station to another. In this case, we reduce the number of sweeps to that which makes sense and then accept the residual risk.