Wednesday 22 January 2014

Cisco WLC 802.1X Client Exclusion Sometimes Doesn't Work...

I came across an issue recently and though I'd blog it for others...  Cisco WLC client exclusion not working for some 802.1X clients.  In my case this is using CUWN (WLC v7.x, Cisco ACS v5.3).


This issue effects what I call the 'basic' BYOD setup.  Where certificates aren't in play and AD is referenced directly by the client using EAP methods - i.e. PEAP (MS-CHAP-V2).


The issue being reported was AD account lockout being triggered by WLAN clients.  I thought that this would be unlikely as the WLC excludes clients by MAC when they are failing consistently.  The WLC registers RADIUS-REJECT messages and after 3 failures excludes the client.  The WLC drops all RADIUS requests from the excluded client MAC for the period of the exclusion timer (as configured for the WLAN).

I began testing with an iPhone 4 (iOS 7) and sure enough it was able to generate as many failed authentications as it liked without being excluded.  The client debug and AAA logs showed that the WLC isn't excluding the client because it re-associates after just one RADIUS-REJECT message.  The RADIUS-REJECT counter on the WLC never reaches 3 and the client isn't excluded.  Exclusion works fine for clients that repeat 3 auth attempts without disassociating.

I wonder why the WLC would purge the RADIUS-REJECT count when the client disassociates?  Is this by design or due to changes in modern 802.11 driver logic?  I think Windows drivers tend to play more nicely.

The moral of the story here is that this is one (of potentially many) ways that the AD is opened to malicious attack.  Get smart and implement additional measures to protect AD.  For the WLAN use EAP-TLS authentication.  Implement two-factor auth for all other public-facing services.

Have a look at my Building BYOD blog for further info on securing your BYOD services.

Wednesday 18 December 2013

Wi-Fi Certification: CWNP vs Cisco

I thought I'd do a quick blog on WLAN certification paths...

Firstly, I'd like to say how great it was to begin reading the CWNA and CWDP study guides.  As a wireless engineer if you only ever read two books read these...  You'll be a great engineer if you apply that knowledge to business.  If you follow the past and present CWNP guys on twitter you'll find that they are not only hugely talented WLAN geeks but also very intuitive business people.  This comes across in the CWNP literature and exams.  They are steeped in foundation knowledge of the standards and protocols, plus deployment strategies aren't tied to a vendor.

Moving onto Cisco... From a career perspective Cisco hold a huge majority and Cisco Partners want you to have Cisco accreditation. You'll be sought after in the partner world if you can provide exams that enable Wireless Specialisation for resellers.  This is the reason my Cisco certs came first.

My main gripe with the Cisco wireless exams is that lots of questions are product and version specific. It's almost like there is an element of presages knowledge that Cisco feel needs to be understood by engineers.  For example, how many clients does a 2500 WLC support?  The unwritten rule is that the engineer needs to know which version the exam was written for... Make sure you keep those old data sheets and configuration guides - these numbers change!

Here's a CCNP Mobility question that made me laugh. "You have wireless clients and wireless tags supporting CCX, do you need to buy an AeroScout license to track them?"  The answer is no... you'll know this if you've sold/deployed it.  But is it really a question that defines a good engineer, or a sales checkbox?

I'm about to begin the CWAP and CWSP, and very much looking forward to it.  I'll then be aiming to get my CWNE by the close of 2014.  A qualification that I already consider to be a mark of a top-class wireless engineer.

A final thought... Now that I'm doing the hiring.  I have a CWNP qualified guy and a Cisco qualified guy.  Who will get the job?

Wednesday 16 January 2013

Delivering Customised Apps using MSAP


The arrival of the Hostpot 2.0 / Passpoint / 802.11u revolution is imminent (see my previous blog for more info).  I've been looking at how apps and content can be intelligently delivered to the 'information generation'.  If the info is useful, they want the app for it... 

You may wonder why aren't we seeing cool apps being pushed over public Wi-Fi already?  Well... It means the vendor, integrator or the customer needs to work on developing the app.  This can be a challenge, particularly if the app needs to be developed for a wide variety of devices (new model resolutions, new features, bug fixing, etc).  Whilst only a few organisations have made that investment so far... 'monetising' Wi-Fi through 802.11u may well be the catalyst for rapid development in this area.

Another protocol that will kick-start customised app delivery is Mobile Service Announcement Protocol (MSAP).  MSAP is a way of automatically delivering apps and content to 802.11u enabled devices that support the protocol.


Examples of MSAP services:
  • Targeted context-aware customer information.
  • Location maps - nearest toilets, baby change, ATM, etc.
  • Promotional offers for retail units.
  • Stadiums - action replays, statistics, commentary.

How does MSAP work?
  • MSAP is Cisco proprietary protocol for service discovery. 
  • MSAP is transported via 802.11u GAS (Generic Advertisement Service).
  • Wi-Fi clients receive icons and service URLs, they show up in the device OS (if enabled by user). Referred to as 'transient apps', they are removed when you leave the service area.
  • Content delivery can be location-aware, i.e. you only receive it when you enter an area.


What do you need?
  • Cisco MSE - operates as MSAP server, delivering XML content (a URL) to the MSAP device.
  • MSAP supported device - currently just Qualcomm SnapDragon S4 chipset. As of Q1 2013, only Android and Windows phones contain this chip.  The notable exception here is Apple devices…
  • Content webserver, mobile app developer.

In Summary

MSAP is definitely a protocol that has potential, there is plenty of demand out there for context-aware application delivery.  Initially it will be a quick win for retail - sales and marketing promotions.  With development there will be real-world benefits to users in a large building, university campus, hospital, shopping centre, or stadium.

The main drawback I see at present is that MSAP isn't a standard. At present only a selection of late 2012 Android and Windows phones running the Qualcomm SnapDragon chip (Apple don't support MSAP yet).  Users will also need to be made aware of the opt-in device configuration.

On a wider note, I should mention that mobile apps can be delivered without 'Cisco' MSAP.  It just means that it's not done automagically, the user needs to download it from an App Store or captive portal.

Resources:

Tuesday 20 November 2012

Cisco acquires Meraki



Cisco's acquisition of Meraki is an interesting prospect for customers, partners and competitors.  Meraki are an unknown quantity to many, so I thought I would share my opinion on what this means to the WLAN industry.

As a WLAN engineer that has been working with Cisco for 10 years I'm pretty happy about it.  I have been looking at Meraki for a while and picked up one of their AP's a few weeks ago.  If you read my blog about BYOD you'll see I have a lot of love for the Meraki product.

Meraki have taken the controller to the cloud, they look after it.  You choose upgrade windows and never have to pay for resiliency, new hardware, software upgrades or power bills.  You can also buy switches and security gateways for the full feature set.  All are cloud managed through a clean and simple web GUI.  The main selling points of the solution are as follows:
  • Plug and play access points (DHCP to Internet is all you need)
  • Switch and security gateway appliances for additional features
  • Feature-rich WLAN services - URL filtering, firewall, VPN
  • Slick cloud-based management GUI
  • BYOD out of the box - including the illusive trusted CA (see Building BYOD blog part 2)
  • Free MDM for iPhone, Android, Windows, OS X
  • Layer 2-7 stats and reporting


Cisco's ageing WLC-centric infrastructure has been struggling to compete in the SMB channel for a while now.   For the last few years companies like Aruba, Aerohive and Ruckus have been turning heads.  However, they will now lose many of their (compelling) arguments against Cisco's previously appliance-heavy infrastructure.

The $1.2bn price tag will be questioned, but I feel that this acquisition is vital to Cisco's strong position in the WLAN industry - and worth the investment.  By acquiring Meraki, Cisco will be able to wade back into the SMB market.  I can only see them expanding their customer base.

Cisco partners will be saying "Awesome, now we can offer BYOD and MDM at low cost".
Cisco competitors will be saying "Damn... We had them on the ropes...".
Meraki partners may be saying "Meh… Now we're going to lose out to Cisco Gold partners"




What does it mean for Meraki products and customers?

Anyone who has recently bought into the Meraki revolution might be worrying about what this acquisition means to them.  If it is anything like the Airespace acquisition it will go like this:
  • Cisco will rebadge the Meraki products and maintain current pricing.
  • Cisco will honour all current support contracts.  Support will be migrated to Cisco TAC.
  • Cisco will phase out the Meraki hardware for Cisco hardware, then offer migration deals.

We're all trying to envisage what Cisco will attempt to do with Meraki.  They may leave them to operate in isolation.  As is stated by Meraki here http://www.meraki.com/company/cisco-acquisition-faq

I don't think cloud networking will extend into the Cisco product set quickly.  However, there is nothing to stop network appliances being offered with 'local' or 'cloud' firmware.  Much the same as autonomous or lightweight AP's today.  However, Cisco will need carefully manage how they offer these products  to customers.

The shift from where Cisco are now with their 'tin' approach to where Cisco could be with an 'IaaS' approach is huge.  This conversation goes way beyond my WLAN blog....

Final word... I'm fortunate enough to be a member of the Cisco Mobility PVT.  So I hope to be able to report back about the good things are going to emerge from Cisco in the near future.  Watch this space...

Mental note! Get CCIE before Meraki technology is added to the exam...

Thursday 15 November 2012

Building BYOD part 4 - Choosing the right vendor



A Little History… 

2005 - Aruba and Cisco hit the market with "captive portal" technology that is prevalent in hotspots today.  Aruba's product was better.

2009 - iPhone arrives… Amigopod (soon to be acquired by Aruba) are the first company to market with a BYOD gateway with PKI integration, but it only supports iOS devices and requires SSID switching for client on-boarding.

2010 - Mobile Device Management solutions arrive offering alternative to WLAN vendor solutions for mobile devices.  Smooth profile delivery mechanisms. MobileIron, Airwatch, Good, Zenprise.

2011 - Cisco release Identity Services Engine, but are still behind Amigopod on development.  Other vendors introduce MDM through partnerships.  PPSK was been introduced as a better alternative to web login by Aerohive and Ruckus.

In 2009 vendors succumbed to the fact that there is a world beyond Windows.  The behaviour of mobile devices also made WLAN vendors realise they needed to find an alternative to web login… A raft of new MDM vendors also emerged.  The recent challenge has been to develop web-login portals that integrate with MDM agents to support multiple device types, operating systems and user databases.  The goal for all vendors it to be able to push EAP-TLS profiles and certificates to a wide range of OS - Windows, OS X, iOS, Android, Windows phone, etc.  But also to be able to support traditional web-login or PPSK solution for non-compliant devices and users.

BYOD portal technology is a logical progression from the basic web-login solutions of 2005.  The ideal BYOD portal product offers the following:
  • Single point of entry for all users
  • Highly customisable walled garden website
  • Traditional web-login for visitors
  • BYOD on-boarding options for employees
  • Client agents for profile delivery
  • Support for multiple OS
One thing I feel that is lacking in most vendor offerings is the ability to customise the portal for corporate branding and content delivery.  This is an important part of corporate identity that vendors haven't made enough effort to accommodate.  This may be explained by the aggressive recent development of BYOD.  In reality, vendors have struggled to develop their own BYOD solutions.  Several have partnered with BYOD solution vendors, or simply referred customers who want BYOD to MDM solutions.  

BYOD Vendor Options

Product maturity is the big question.  Not just in terms of the breadth of device OS support, but also through software development.  As you can see from the timeline, Aruba have a mature product with PKI integration.  Cisco have invested heavily in the ISE product and only in recent releases has the feature set and functionality become comparable to Amigopod.  

Both Aruba and Cisco offer BYOD focused security appliances with a multi-purpose captive portal with BYOD integration for IOS and Android.  Aerohive have also recently developed their own portal that offers MDM integration via the JAMF solution for Apple devices.  Meraki have stormed into the BYOD market with a multi-OS BYOD solution that offers an MDM/client app covering all major platforms (Win, OS X, iOS, Android).  This cloud-based "free MDM" approach is so easy to setup in comparison to all other vendors that the cost-savings are huge, not just in MDM costs.  My concern here is that traditionally WLAN vendors aren't focused on MDM.  Will they stay on top of development around bugs, security alerts, OS updates, etc?  Will their support teams be on-par with an MDM vendor?

A note on PPSK - Both Aerohive and Ruckus offer PPSK which is a big improvement over web-login.  This is going to be a great solution for most companies.  Though if tight security is a concern, I would be interested to know if they are able to tie a user to the client session for litigation against Internet misuse.



In Summary


For the last few years Aruba Amigopod and MDM have been the leading BYOD options.  There has also been an IOS exclusivity in the WLAN vendor space until recently.  Cisco have caught up somewhat with Aruba and other vendors are offering well-rounded solutions with less painful deployments. 




Finding the right solution for an organisation will be about taking all the info on board from this and previous blogs, putting it all together and cross referencing agains the vendor solutions.  Not an easy task... 

I do think that SME customers will quickly move away from vendors with appliance-heavy architecture.  Cisco and Aruba should be worried about innovative and agile vendors like Aerohive, Meraki and Ruckus coming in cheaper and winning customers.

Wednesday 3 October 2012

Building BYOD pt 3 - User Experience & Productivity

In part 1 we looked at BYOD requirements, then part 2 addressed the security of BYOD service as a whole.  In this blog I'm going to cover User Experience & Productivity.

User experience is generally defined by 'BYOD groups'.  Group membership will be dictated by both the user role and device support.  Users are generally split into two parent BYOD groups; domain users and non-domain users.

Domain users - Domain users should get a smooth process that automates the delivery of the WLAN profile.  This may require agreement to T&Cs regarding use and disk encryption, strong password, remote-wipe, etc.

Non-domain users - Non-domain users will accept that they need to be authorised by a sponsor before being on-boarded.  So they will wait for that to be done, or if arriving for an event would hope it was done in advance by the organiser.  In most security conscious businesses the trade-off is to get some contact details for the user.  Ideally their credentials are sent to them via SMS, guaranteeing a valid contact number.  Alternatively, and more commonly the credentials are emailed or printed.  An important note for non-domain users is that their account should be time-limited.


Perfect BYOD
  • Use a captive portal landing page for new users.
  • Use device profiling to define the user's device.
  • Use Active Directory to validate domain users. 
  • Use an MDM client-side app to auto-configure profiles and manage device security.
  • Use 'non-domain' Certificate Services for WLAN security.
  • Assign employees to VLANs by AD security groups.
  • Use a single SSID and Change of Authorisation (CoA) to apply VLAN ID.
  • Apply QoS using WMM, DSCP and L7 application awareness.

The above approach is a 'perfect world' scenario.  However, not many WLAN vendors offer ALL of this and you will need to review both your WLAN and MDM vendor before finding the right solution and price for your chosen BYOD model.  Pen-testing is also likely to be a prerequisite for selection in high-security organisations.

As I'm writing this I have realised that I should really write another blog on the different WLAN vendor approaches, look out for BYOD blog part.... 4!


Productivity

"BYOD improves productivity" we see this mantra everywhere in Wi-Fi.  However, BYOD doesn't necessarily improve productivity.  Many organisations have introduced better workflows through mobile apps and systems that work just fine over 3G/4G.  

The question sometimes becomes "How will BYOD improve upon existing 3G/4G productivity?".  Well, BYOD improves productivity over 3G/4G in these scenarios:
  • My signal is terrible, there isn't enough throughput in areas where signal actually exists.
  • Most of our BYOD users have Wi-Fi only.
  • I want to use voice or video apps, I have a local VoIP gateway that supports SIP clients.
  • I want to use Bonjour services - AppleTV in meeting rooms.
  • I want my trusted WLAN devices to access local file and print servers.
Many organisations see BYOD as a logical next step up from guest services, and often use the same DMZ for BYOD - pushing traffic directly to the Internet.  In my opinion, BYOD must offer LAN access to maximise productivity and truly differentiate from 3G/4G.  3 out of the 4 scenarios require LAN access.

The key takeaway here is that access to local networks is a game changer.  For employees, having access to printing, file shares and media services is where BYOD makes headlines.  So, it's important to get the blend of usability and security right… remember, execs want Apple TV in the boardroom - just make it happen.

Here are a few tips for a productive BYOD design:
  • Consider traffic flows.
  • Decentralise WLAN architecture for trusted devices.
  • Don't over-engineer device security.
  • Develop tablet optimised corporate apps.
  • Develop a secure cloud service for mobile focused apps.

The Social Media Meltdown

Finally, the elephant in the corner…. Social media.  Is it a threat to productivity?  I hear mixed opinions on this… 

Access to social media via the corporate network depends on the culture of the business, and many businesses encourage the use of Twitter and Facebook.  Though I do think it's fair to say that many employees will see BYOD as an avenue to their 'personal' digital lifestyle.  This could result in the loss of a fair few hours of productivity if staff begin spending an inordinate amount of time in the toilet... Which is why I have patented the 'Simkins Faraday Cubicle' in 65 countries :)

Joking aside, using a L7 aware security appliance and profiling you could create profiles based on security groups for approved Twitter and Facebook users.  Then limit standard users to say 30 minutes per day.  But is that really necessary?

Thanks for reading!  Next blog will cover the WLAN and MDM vendor options for BYOD.

Friday 20 July 2012

Building BYOD pt 2 - Secure Design

After picking up the business requirements it's time to baseline the BYOD security requirement.  Ask the security decision maker these questions:

  • Will internal systems be accessible via BYOD?
  • Can the endpoints be trusted?
  • Is data loss prevention of significant importance? 
  • Is legislation against criminal activity a concern?
  • Do you have a DMZ or content filtering capability?

The answers to these questions will indicate the need for the design to include perimeter network security, mobile device management, data loss prevention and logging.

There is clearly a spectrum of options here.   At one end you have a self-served 'home user experience' using basic PSK security for Internet-only access using a DSL router, with no consideration to endpoint security or criminal Internet activity.  At the other end you have  account request, authorisation and revocation processes, 802.1X, endpoint security, firewall, web filtering, monitoring, alerting, administrator audits, session logging, etc..

Each organisation is different.  So you'll need to take the customer requirements, then cross-examine them against what is considered to be acceptable operational risk with regards to security.  Let's examine the likely baseline for security in a 'secure enterprise' where you expect to support P2P and LAN traffic.


Step 1 - Wi-Fi Security

For a secure design we're looking at WPA2 with AES encryption and 802.1X authentication.  Choosing the right EAP protocol is important, so here is a simple comparison the two most popular inner EAP protocols - MS-CHAP-V2 and TLS.

Protocol
User Experience
Bulletproof?
MS-CHAP-V2
The user enters their Windows username and password at first connection.  This may need to change regularly, which is annoying for users.
No.  A MITM attack using fake AP and RADIUS server can result in lost user credentials.
TLS
Certificate is installed on the device and can be valid for 1, 2 or even 5 years.  Better user experience.
Yes.  Client and server certs from the same PKI provide a trust chain.  The clients cert(s) are not usable by MITM attackers.

The point I'm making is that PEAP (MS-CHAP-V2) is the easy way to enable BYOD but it isn't fully secure and can be annoying for the end user.  Many organisations are using this method for BYOD without being aware of the MITM attack risk.

The bottom line is that to be bulletproof certificate chains need to be trusted between the client and server, and private keys should be non-exportable.  That said, most security conscious organisations baulk at the idea of putting private PKI certs onto BYOD clients.  If this is the case you may want to look at a third-party CA.


Step 2 - Device Security

Specific concerns over BYOD are around disk encryption, OS security, private data and certificate/credential storage, malware, viruses, hack tools, etc.  Therefore, consider identifying a BYOD approved set of devices and operating systems that meet your requirements.  If device security is important then you'll need a Mobile Device Management platform to manage the device and applications.  Good For Enterprise is an example of a sandboxed Exchange application that encrypts mail, contacts and calendar.

There are lots of variables in terms of devices and operating systems.  Supporting multi-OS can be complex and many organisations choose to simplify this by drawing the line at Apple iOS.  Which supports SCEP, has less weaknesses and is easier to integrate with business.

Of course this is a fairly exclusive approach and the customer may want to consider building some differentiated BYOD services.  Perhaps offering a limited service to users who don't have a supported device or prefer not to sign up to MDM.


Step 3 - Network Security

Your Wi-Fi client VLANs will require different LAN firewall policies, so consider using CoA (Change of Authorisation) as a way of segmenting clients to offer diverse services.  CoA requires an element of client profiling or posture validation, allowing clients to be assigned to a specific VLAN.  CoA also benefits from allowing a single SSID to host multiple services, which avoids the 802.11 overheads of multiple SSIDs in the air.

You'll also need to consider where you allow these untrusted client VLANs to exist, and how you'll firewall their network access.  This will usually be an 'edge versus DMZ' policing decision (decentralised or centralised firewall policy).  Both options are viable given the right WLAN vendor and LAN design, and there are wider discussions to be had on this topic.

Finally, network security isn't complete without logging and audit trails.  If you offer a BYOD or guest service you really ought to consider the impact of criminal activity.  The important things to track are client usernames against Internet activity - logging from two platforms.  A service like Splunk is ideal to gather syslogs, traps, log files, etc.  


The message for part 2 of Building BYOD…


To be bulletproof you'll need a PKI for certificate delivery to your trusted devices.  You can also consider using posture assessment and CoA for a layered BYOD security policy that offers differentiated services to lesser trusted (or capable) devices.

When discussing BYOD, make sure you think about the wider picture, it's not just a decision over which MDM platform you prefer.  Consider every layer of security - the device, applications, wired and wireless infrastructure and Internet service.

That's it for Secure Design.  In the final part we'll move onto User Experience and Productivity.
http://uk-wireless.blogspot.co.uk/2012/10/building-byod-part-3-user-experience.html