But that credit card weirdness is nothing compared to the one I’m about to describe.

Before we do that, let’s take a moment to discuss the design principle of failing securely. The general idea is that if a security mechanism fails, it should fail closed. If your firewall crashes, it should block all traffic, not allow all the packets through. If the power source to your card key system is interrupted, it shouldn’t unlock all the doors. If the connection between your application server and your LDAP directory is severed, subsequent authentication requests should be rejected, not approved. This is not rocket science.

So back to credit cards. I had a conversation last night with an old friend who related a bizarre situation they had encountered during the QA process for one of their web applications. One of their tests involved repeatedly attempting a credit card transaction using a canceled/expired American Express card. Here’s what they saw in their logs, paraphrased by me:

Attempt 1: Denied
Attempt 2: Denied
Attempt 3: Denied
 .
 .
 .
Attempt 49: Denied
Attempt 50: Denied
Attempt 51: Approved

What the…? Approved? That can’t be right. So they ran the test again. Every time, after multiple consecutive rejected attempts, the transaction would inexplicably go through. The threshold wasn’t always 50, but the general pattern was consistent — keep trying and eventually it’ll work. Clearly, this had to be a bug in the code, but a deep-dive into the guts of the application turned up nothing. The application security group got American Express on the phone to see if they had any insight on this odd behavior. The answer? They didn’t concede the failure was on their end, despite log data showing the successful authorization codes.

My gut instinct would be that the application requesting the transactions wasn’t failing securely (e.g. network connection to AmEx timed out, so just approve the transaction). But that explanation wouldn’t account for authorization codes coming back.

So what in the world is going on here? Why would the system behave this way? Is it by design? I can’t think of a single legitimate use case for failing open like this. If this is actually a design decision by the credit card companies, I have no doubt that someone in our audience knows the rest of the story.

First of all, as background information, I learned the Thai alphabet (script with 44 consonants and 32 vowels) nearly 20 years ago, so I have have a pretty decent foundation for the Thai language compared to most foreigners visting or working in Thailand.   I can read (slowly) and speak better than 99.99+ percent of all foreigners in Thailand.  For this reason, I thought it was ”the right thing to do” to redirect my career to a “new challenge” in the business climate of Thailand as I continue to improve my foreign language skills.   I wanted to help Thailand progress in IT and IT security, so where else would I go but where I have second language skills?

This was no small decision as you can imagine.  Your career and life changes quite dramatically when you give up a long established consulting practice in the US and dive into business in a foreign land, seeking a new challenge.  I can frankly tell you thatit is more difficult to do business in Thailand (as a foreigner) than I expected, for a number of reasons.  Here is my first off-topic post on this topic.

First of all, it is not legal for foreigners to directly own land in Thailand.  Foreigners can ”own” land using a variety of legal loopholes, proxy owners and shell companies; but all of this is risky and not advised.  Many foreigners lose a lot of money coming to Thailand and attempting to buy land via various “structures”.  Some get lucky, but the entire process of foreigners buying and selling land is quite risky and not recommended.

Foreigners can legally own condominiums, under certain conditions, but this “foreign market” results in inflated prices for condos in Thailand that are traded in an “artificial market place” designed for foreigners.   Condos in Bangkok and major resort areas that are up-to-par with condos in the US can easily cost more than condos in major cities in the US.  Hence, the cost of living in Thailand is not as economical as some might believe when you visit Thailand as a tourist.

Second, business in Thailand can best be described as protectionism with discrimination where the government has placed many barriers to entry to foreigners working and competing in Thailand.     Every foreigner must have a work permit and these work permits are expensive and time consuming to maintain.   If you own a business you must pay high professional service fees for “auditors” to perform annual and semiannual audits regardless of how much income you have (including zero).   Firms in Thailand charge thousands of dollars for these ”audits”.      

Third, if you operate a business in Thailand, you must have a place of business (you cannot legally work from your condo you bought at high prices!), so you are forced, by law, to lease office space.   Foreigners from the US, for example, must be paid a minimum of 50,000 Thai Baht per month, so the government will take 10 percent of that each month as their share of tax withholdings.  Startups with no income simply pay income taxes against their personal savings to comply with the law.  Therefore, to start a company and maintain the business in Thailand, you are required to pay significant startup, monthly, semi-annual and annual fees, permits, tax, leases, visas, etc. 

Forth, generating incoming revenue in Thailand can be quite difficult in a climate of both protectionism and discrimination.   In Thailand, it is easy when you are spending money.  This is the ”Land of Smiles” that tourists see and experience.   However, when you are legally permitted to work in Thailand and trying to generate in-country income, you cannot help but notice the protectionism and discrimination against foreigners working and living here.  Many foreigners working in Thailand just “give up” because the barriers to business success are quite high.

Fifth, on top of the challenges of protectionism/discrimination regarding foreigners and foreign investments, which I have only just scratched the surface here, is the overall global business slowdown combined with a climate of political instability which I am sure you have seen in the news.  Thailand has seen 18 coups since 1932.   Currently, Thailand is under a State-of-Emergency  which negatively impacts business even more.  Sound challenging? 

Most people who live and work in Thailand have the opinion that it is far better to enjoy being a tourist here. Working in Thailand is very difficult for many reasons.   Being a tourist in Thailand is completely different than working here.  When you are a tourist, foreign currently flows from you into Thailand, so life in Thailand as a tourist is fun and friendly, hence the “Land of Smiles” you have heard about or experienced.     However, when you are working in Thailand and trying to generate income from Thailand versus bringing in foreign currency, you don’t see the “Land of Smiles” quite the same anymore.

Without getting into too many details in this post, I can simply say that a foreigner doing business in Thailand experiences both protectionism and discrimination.  I came to Thailand hoping to contribute my experience to help the Kingdom.  However, sometimes it feels like foreigners are only welcome if you are working for free, giving seminars for free, and bringing in lots of foreign currency here.

In a future post on business in Thailand I will dive into some details on a number of topics that might be of interest to readers who will never have a chance to come and work here.   

First of all, I learned the Thai alphabet nearly 20 years ago, so I have have a pretty good foundation for the Thai language.   I can read (slowly) and speak better than 99.99+ percent of all foreigners in Thailand; so, I thought it was time to redirect my career to a “new challenge” in the business climate of Thailand.   

This was no small decision.  Your career changes dramatically when you give up a successful consulting practice in the US and dive into business in a foreign land for a new challenge.  I can frankly tell you that often the challenge is sometimes overwhelming.    It is quite difficult as a foreigner to do business in Thailand.

First of all, it is not legal for foreigners to own land in Thailand.  Foreigners can ”own” land using a variety of legal loopholes, proxy owners and shell companies; but all of this is risky and not advised.  Foreigners lose a lot of money coming to Thailand and attempting to buy land.  Some get lucky, but the entire process of foreigners buying and selling land is quite risky.

Foreigners can own condos, under certain conditions, but this results in  inflated prices for condos in Thailand that are traded in an artificial market place.   Condos that are up-to-par with condos in the US can easily cost more than condos in major cities in the US.  Hence, the cost of living is not as cheap as some might believe.

Business can best be described as “protectism” where the government has placed many barriers to entry to foreigners working in Thailand.     Every foreigner must have a work permit and these work permits are expensive and time consuming to maintain.   If you own a business you must pay high professional service fees for auditors to perform annual and semiannual audits even if your business has no income yet.   Firms in Thailand charge thousands of dollars for these ”audits”.      

In addition, if you operate a business, you must have a place of business, so you are forced to lease office space.   Foreigners from the US must be paid a minimum of 50,000 Thai Baht per month, so the government will take 10 percent of that each month as their share of tax withholdings.   Therefore, to start a company, you will pay a lot of money in startup fees, permits, tax, leases, visas, etc.  The entire system is designed to secure money from you, even if you do not have a penny of incoming revenue.

Of course, generating incoming revenue can be quite difficult in a climate of protectionism.   In Thailand, it is easy when you are spending money.  When you are trying to generate income from Thailand, as a foreigner the challenge can seem overwhelming at times.   Many foreigners here give up because the barriers to business here are very high.

On top of all these challenges, which I have not described in detail, is the overall global business slowdown combined with a climate of political instability, which I am sure you have seen in the news.  

Most people I know say it is better to be a tourist here.   Being a tourist is completely different.  Money flows from you, so life in Thailand is fun and friendly, complimentary to the “Land of Smiles” you have heard about.     However, when you are working to have money flow the other direction, flow to you versus away from you, you don’t see the “Land of Smiles” as tourists experience.

Without getting into too many details, I can simply say that a foreigner doing business in Thailand experiences protectionism and, to a certain degree, discrimination, and sometimes I wonder if coming here for a “business challenge” was a good idea.    I was seeking a “new challenge” and I got more than I bargained for!

In a future post on business in Thailand I will discuss issues regarding how little value is placed in intellectual property in Thailand and how this adversely impacts professional services.    I will also touch on how this lack of regard for intellectual property impacts a consulting practice.   Also, I will touch on some cultural differences in how Thais appear to view teamwork, which is very different than in the US.

• Certified Information Systems Auditor (CISA) : http://www.isaca.org/cisa/
• Certified Information Systems Security Professional : https://www.isc2.org/cissp

Are You Ready ?
A few basic questions to ask yourself to gauge how ready you are:

• Do I meet the spirit, and not just the letter, of the experience requirements ?
• Has there been sufficient diversity in my experience ?

Five Step Approach to CISA or CISSP Exam Preparation

1. Perform an initial benchmark and assessment of your readiness
2. Read a “survey” level preparation guide cover to cover
3. Perform a secondary benchmark, and compare your readiness
4. Review official, or “deep dive”, preparation materials on areas identified as your weaknesses
5. Re-benchmark, and repeat targeted reviews until ready

CISA and CISSP Preparation

Formalize Requirements for long-term use

Now that you are making security development a lifecycle, it is time to lock down and formalize your security requirements. At this point, you need to take what you’ve learned and begin translating your security principles into something that can apply to multiple releases and multiple levels of your development process.

At a product level, you need to use the security rules created in prior projects to define long-term security requirements. Those requirements will become your core security policies.  Then, at the version level, you should create security requirements that are version-specific and are defined by the security objectives and features you want to address in that version.

Both of these sets of requirements can be formalized in a way that makes them easier to transfer across future product cycles and to modify based on the unique features or security issues of each version.  Making these a staple of your development lifecycle will also ease adoption of these requirements as team become familiar with them over multiple releases.

I would like to touch on one topic before moving on – enforcing requirements. As your team grows and your SDL matures, there is an inherent complexity that comes with managing and enforcing your requirements. In our experience, we’ve found that it is critical to identify a security advisor. Up until now, your company has probably had someone championing security and best practices – either as a formal role or simply as a informal advocate. However, making it a feature of your lifecycle requires dedicated effort to enforce and sustain the requirements as well as monitoring the security ecosystem for changes that may add requirements to your process. The security advisor(s) are the people who will help guide the creation of the security requirements both broadly and for each product cycle; for a smaller team, this may be a single individual. For a larger organization, a team of people may be needed. The security advisor should also evaluate your security policy and apply changes where needed, ensure the product bug database is tracking security issues that can be reviewed later (I’ll get to the Final Security Review in our next post), and guide the definition and enforcement of a security “bug bar”.

Security requirements serve as the backbone of your SDL. The amount of effort you put in defining and enforcing requirements, and keeping them up to date with the current threat landscape will have a direct return on investment in the security and privacy of the product you create. Be careful to document and clearly communicate your requirements to your team, and use them as evidence when talking to your customers about how you ensure the security and privacy of your product.

Reference & Reuse Threat Modeling results & Attack Surface Reviews

Your developers and testers should have access to and be familiar with the attack surface analysis or threat model documents you have created. These documents are invaluable reference tools. Use them to perform evaluate your security from multiple angles:

·         Think about component-level architecture

·         List common pitfalls in writing code, or begin defining and building test cases.

·         Code reviewers can reference threat models and attack surface documents to verify specific attacks were addressed in the code.

·         Architects can use them to identify new areas of potential attack surface based on how new code is written or interacts with existing code.

·         Project leadership can reference threat models or attack surface documents to ensure the completed project meets all security goals.

Building a “live” library of threat models that is accessible by everyone and is designed to be easily maintained or updated is a big undertaking. Based on experience, I would strongly encourage doing this early in the evolution of your security lifecycle to avoid losing valuable data and to prevent the sheer volume of data from becoming unusable. I have heard of some companies using wiki technology as their library for threat modeling while others may use searchable documents, spreadsheets, or websites to store/sort/share the information. Whatever method you use, it is important to anticipate the accumulation of a large set of information that should be easily used and shared across the organization.

I would like to do a deeper dive on the importance of security code reviews as part of your “walk” evolution. Security code reviews focus on identifying insecure coding techniques and vulnerabilities that could lead to security issues. The goal of a review is to identify as many potential security vulnerabilities as possible before the code is deployed. The cost and effort of fixing security flaws at development time is far less than fixing them later in the product deployment cycle [from Improving Web Application Security]. You should create a process where top security developers actively review code within the context of known threats prior to deploying your code. Leveraging the existing documentation about feature design is a vital reference piece to make those security reviews successful.

Later this week, I’ll close the series with a look at final security reviews (FSRs) and how to document your work for post-release and next-release reference.

In the meantime, we’d like to hear from you:

?        How do you express your security requirements? Do you use a checklist, a whitepaper, or something else?

?        What challenges have you faced in enforcing requirements across your teams?

?        How have you implemented threat models or attack surface reviews?

This blog gives us a place to talk about our experiences from using the SDL here at Microsoft and hopefully provide useful information that will help you implement it more effectively at your company.  So, I would encourage you to use the Comments section at the bottom of each post to ask questions, give us feedback, or request other topics for us to cover.

Some quick definitions before we dive in. I’ve been using the imagery of learning to “crawl, walk and run” as a way to provide some basic starting points that would move your organization toward implementing the Security Development Lifecycle (SDL).  “Walking” is the point where your security development practices become a lifecycle – a repeatable, reusable process that makes security a part of your development culture. To relate the analogy to SDL a bit more closely, think of crawling as the “SD” in SDL. For this post, we’ll continue to talk about walking – or adding the “L” in SDL.

Let’s jump into another component for adopting the Microsoft SDL to expand your own Security Development Lifecycle.

Expand Security Training

Once you have management approval, it is necessary to gain grassroots acceptance of the changes – at the developer, QA/test, and PM levels. If you have been “crawling”, you have probably already implemented some sort of discipline-specific training around things like threat modeling, using compiler defenses, and fuzz testing. Now that you are building a lifecycle, your goal for security training should expand. Security training should be about creating an environment where writing secure software is everyone’s mission. While security training should be undertaken with the goal of understanding security issues and how to address them, good training (and instructors) will also explain why solving security problems is in their best interests and create an environment where they know voicing security concerns is encouraged.

Training has been one of the earliest and most important elements of the SDL at Microsoft. From our experience, we learned that the most effective approach is to divide your training into two tracks: general security principles and role-specific security practices. Before I jump into the details, I want to encourage you to also read Shawn Hernan’s very good post about SDL training that highlights some of the ways to make security training effective.

The general security principles should explain why security is important, how you define security requirements, the process you will use for writing and validating secure code, and how security relates to each phase of the lifecycle or unique roles contributing to the development process. A key factor for building a development lifecycle is educating your individual contributors on the value of investing in security. Of course changing culture takes time, but using the opportunity of structured training to explain your principles will be one of your most effective platforms for influencing change.

At this point in your organizational maturity, you are also beginning to expand your security thinking by focusing on each role in the development process. Discipline-specific security training is where you dig into the details of implementing a Security Development Lifecycle.

·         The developer needs to understand the practical details of how to write code securely, how to set compiler flags, what a security code review means, how to avoid using banned APIs, and what tools are available for them to perform security analysis before checking in their code.

·         The QA/tester needs to know how to set security rules in test tools, how to perform penetration testing, and what the security quality criteria is for your product, or how to file a security bug.

·         The PM needs to understand how to define measurable goals or how security policies can be factored into feature design.

·         The business decision maker of your organization should understand how to track security metrics alongside other product measurements or how security policy plays a critical role in the overall quality and value of your product.

·         Finally, it is critical for the employees occupying all job roles to understand the value of threat modeling – both as a tool for understanding threats early in the design phase and throughout the development process as a key barometer to the security pulse of your product.

Discipline-specific training will be the place to address these issues for your organization. In case you were wondering, all job roles should be required to attend both types of security training before working on your product.

Our new SDL website [http://www.microsoft.com/sdl] will be a very good place to watch for future training materials. The SDL Training and Resources page has some useful material up now and more will be coming in the future.

That’s Part Two. In Part Three, I will discuss the important “walk” components of formalizing security requirements and reusing threat models and attack surface reviews. Then we will close with the discussions on conducting final security reviews, and managing post-release documentation.

I’d like to hear if anyone is using the concept of “crawling” and “walking” to implement SDL in your company.

?        Do you provide security training to your employees today?

?        Do these additional training topics make sense in your organization?

?        What would you add to this that is unique to your application or company?

photo credit: нσвσ

1. Be A Security Cool Cat: Place penguin stickers on every surface in your cubicle. Stick at least 3 on the dual boot company issued laptop (that hasn’t had a kernel upgrade in 6 months). Use BlackHat stickers for bonus points.
2. Be An Undercover Open Source Evangelist: Unfailingly, recommend open source solutions as more secure. Be sure to quote ‘more eyes, less vulnerabilities’. Recite frequently . Always forward security advisories about commercial products to your boss.
3. Walk the Tech Talk: Learn at Least 10 Bash Keyboard Shortcuts. Treat this as a party trick. Perform rapidly in sequence whenever anyone watches your screen. Giggle and pass the keyboard over and say ‘Your turn!’.
4. Be All Knowing, Jedi Warrior!: Say ‘Trust but verify’ whenever you are asked a question you do not understand. Make it clear in meetings that you trust no-one and “verify” solely through a Google/Secunia search.
5. Impress with a Penetration Test!: Download Metasploit, spend 7 hours modifying the web interface: create custom graphics and hack up the CSS files. Start Metasploit running before you leave for the day. Use Camtasia to capture all screen activity so you can review in the morning. If all went well upload to YouTube and link out via facebook.
6. Practice Defense In Depth’: When you are asked ‘What is the Risk?’, grin inanely and say ‘I’ll tell you after I break out the vulnerability scanners’. Run at least 3 vulnerability scanners to get ‘defense in depth’.
7. Latest *Is* Greatest!: Clipboard stealing attacks are *always* a bigger issue than the CISCO infrastructure with default passwords (how did they get there?!).
8. Educate The Great Unwashed with a Deep Dive Security Awareness Program. Educate end-users about Cross Site Scripting and SQL injection attacks. Don’t invite the outsourced developers - they already know this stuff and have deadlines to meet.
9. Impress Your Peers - Perfect the RFC Shoutout: Pick at least 10 common protocols and learn the associated RFC numbers. Intimidate IT colleagues by shouting out the RFC numbers whenever they mention the protocol.
10. Start A Security Blog: What Can I Say?

About Milton Security Group LLC

Success in the 21st century is defined by your agility in a changing time. This includes adapting to the needs of your employees, contractors, outsource providers on the workforce side and the changing landscape of how to provide the right access to each one of these groups. Your current infrastructure may be limited in its ability to change as well. Real time auditing and control is required in this age, The Age of Compliance(T).

Milton Security Group LLC is a security company with a consulting practice. The Principals and Staff at Milton Security are dedicated individuals with many years of experience with diverse organizations from small businesses to government agencies. Combined with this and our unique range of experience and knowledge, Milton Security serves only one purpose, helping our customer's succeed.

OK, not really too much there. They are a security company with a consulting practice. I did a little more digging. They have two job openings posted, one for a Sr Systems Engineer for the current and next generation of MSG NAC products. I guess this is the guy who will continue on the development of the Vernier line.

But you guys don't pay me what you do to stop there do you? I did some more digging. Seems that Milton Security is the brainchild of its founder and CEO, James McMurray. I did some more digging and it seems James is the former head of the SE group at Vernier, what a surprise! Looks like he was able to get them to let him take over the IP and run with it. I bet he and his friends paid little if anything for this.

People lets get real here. I applaud James for biting this off and wish he and his band of merry men the best of luck. But is this fair to the people who spent all that money on the Vernier boxes. At best Milton will be pressed to keep up with the snort and nessus signatures the Vernier boxes use. I guess being this small, without VC money behind them, they might be just better off using the Tenable and Sourcefire signatures and hope that those guys figure they are too small to sue.

If you are a Vernier customer you have to be checking your underwear. I mean do you want Milton-Bradley supporting your NAC system? This isn't board games we are talking about here. There are too many replacement and trade up offers from StillSecure and other NAC vendors for you to want to be a guinea pig in yet another experiment from the folks at Vernier. How many times do you have to get burned before you learn? You deserve better!

The fact that they’re such common ‘buzz words’ in today’s IT world makes people hesitant to ask questions. You know we IT-folk don’t like admitting we don’t know everything about anything! However, these are rather simple concepts with extremely complicated components and 98% of the technology world doesn’t really know as much as they’d like to about NAC and 802.1X. You’re not alone.

And so, here’s a short technology primer for you, to give you a little insight into the IEEE 802.1X standard and where it falls into the NAC picture. I said I was going to keep this short, so hang with me here.

What is it?   802.1X is an IEEE standard for Port Access Control, also referred to as Port-Based Network Access Control, but that term gets a bit confusing, so I prefer the former. It actually started about 10 years ago, and has been edited and revised since then to add support for new technologies, including adding some specific attributes for wireless implementations.

What does it do?   With 802.1X you can have switch ports, by default, be closed, or shut off. These ports will then only be opened once a user attempts to connect to the network and has been successfully identified as someone who is allowed access. At this point, we would say that this legitimate user is ‘authenticated’. Until this happens, no standard network traffic passes through the 802.1X port- so whatever is trying to connect will not even get an IP address. No IP address = no network access.

Why would I use it?   In a wired environment, you can use 802.1X to extend some physical or layer 1-type security to the edge. In a fully 802.1X-enabled environment, imagine every edge port is off, and completely inaccessible, until an authorized user attempts to connect through it. It’s a great way to secure edge ports, as well as infrastructure connections. You can use 802.1X to authenticate your network devices to one another, or to the network, and pretty confidently eliminate any chances of gaining rogue devices.

Note that, in reality, 802.1X is not something you wake up one day and willie-nillie enable on every port. You’ll want to start with edge ports in public areas, such as conference rooms, then roll out the rest in phases.

In the wireless world, 802.1X is the chosen authentication method to provide enhanced key exchange and rotation for a more secure wireless experience. In fact, it’s been so widely adopted for this use, that it’s commonly mistaken for a wireless standard (802.11 instead of 802.1).

How does it work?   Without dragging up a bunch of terminology you’re probably not familiar with, let’s talk about a couple of basic concepts. 802.1X leverages (or can leverage) your existing infrastructure. If your switches are 802.1X-capable, then they’re ready to go. How do they know that user trying to connect is legitimate? Your 802.1X switches are talking to your RADIUS server, and your RADIUS server is talking to your Directory (AD, eDirectory, or other LDAP). All stuff you probably already have.

You do need something called a supplicant on the endpoint. A supplicant is just an 802.1X client- it’s built into the majority of newer operating systems, and you also have the option of 3rd party supplicants that can be delivered/installed just like any other client.

Doesn’t sound too glamorous does it?

You’re probably wondering “where’s all the magic?” Well, 802.1X’s special power lies in the Extensible Authentication Protocol or EAP. Earlier, I said until a port is opened, ‘no standard network traffic’ is allowed through. Well, obviously something is allowed through, or else there would never be a means to communicate- that something that’s allowed is EAP. EAP carries information between your endpoint, through the switch and to the RADIUS server.

What about VLANs?   You’ve probably heard we can provision dynamic VLANs using 802.1X and that’s certainly true. That VLAN assignment actually comes from your configurations in the RADIUS server. The RADIUS server sends back information that includes ‘other’ attributes, such as the VLAN and QoS assignments. With the new RFC standards and RADIUS attributes, we can do all sorts of neat-o things.

What you end up with is a pretty secure, and fairly flexible solution- possibly without having to purchase any additional equipment or software.

And what about NAC?  If you’re wondering how 802.1X and NAC fit together, it’s pretty simple. Most of today’s network-based NAC solutions can work in conjunction with 802.1X to provide a robust solution with Layer 2 and up protection. Other NAC vendors that don’t leverage 802.1X are using a variety of Access Control Lists, either on switches, routers, a NAC appliance, or at the host. If you’re using 802.1X with NAC, we’ll generally say it’s Layer 2 NAC (since 802.1X is a L2 standard) and if it’s IP/ACL-based, it’s Layer 3 NAC. Some solutions will let you use a mixture. [Note: Layer 2 is generally accepted as being the more secure solution, but some vendors will try to pour their layer 3 Kook-Aid down your throat.]

That’s all. I’ve certainly grossly over-simplified the implementation of 802.1X. You do have to properly configure the RADIUS server and setup the switches to communicate with it. The list of EAP methods available is an arm’s-lenght long and supplicants aren’t ever as clear-cut as we’d like them to be. However, omitting the technicalities of integration, I hope you now have a better idea of what 802.1X is, how it works, and why you’d use it.

If you’re a glutton for punishment, I do have a fairly lengthy presentation I put together with a technical dive into 802.1X. If you’re interested in seeing that, email with (form on left) or post a comment (below) and I’ll send it your way.

# # #