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:

Cisco White Paper on 802.11u / Hotspot 2.0 / Passpoint

Qualcomm / Cisco announcement Nov 2012 

Qualcomm SnapDragon Devices

Monetizing SP Wi- Fi 

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.

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.

http://uk-wireless.blogspot.co.uk/2012/11/building-byod-part-4-choosing-right.html

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

Building BYOD pt 1 - Requirements

We've used hotspot style Wi-Fi 'guest' services for years, but they aren't exactly slick for the business or the end user.  It also means that the device will be outside of the corporate firewall.  This type of service will always have it's place, however, you're going to put untrusted devices directly in touch with business systems at some point.

With that in mind, the decision to move to BYOD will be significant for any organisation.  Taking business systems from Windows to a multi-OS mobile environment is a massive challenge in terms of security, user experience, infrastructure readiness and support.  

This blog will be delivered in a few parts.  The idea to is to highlight the design decisions that will help build the right BYOD service for your organisation.

Step 1 - Gather the requirements, here are some examples;

• Connecting & Profiling Users - We need to...
• provide a quick and simple on-boarding process.
• offer self-registration for staff, but not all staff.
• offer long-term accounts for employees and contractors but not visitors. 
• pre-authorise third-party users.
• support any device type, but restrict devices that can't be trusted. 
• deliver WLAN profiles to devices automatically.
• use domain credentials to authorise our employees.
• support VPN for teleworkers.

• User Authorisation & Auditing  - We need to...
• use AD security groups to authorise employees.
• use certificates, but not our internal Root CA.
• know who has authorised our third-party users.
• prevent visitor accounts being created using dummy names.
• be able to audit user sessions by IP address for 12 months.

• Filtering & Prioritisation - We need to...
• allow social media and personal mail
• filter traffic without configuring a proxy server on the device.
• enable multicast services for our business media services.
• allow Facetime and Skype but not Internet TV.
• enable VoWLAN for our SIP solution.
• allocate better QoS and bandwidth profiles to our priority users. 
• use Apple TV in meeting rooms and the conference centre.

• Infrastructure & Endpoint Security  -  We need to... 
• make sure the execs get guaranteed bandwidth for video streaming.
• ensure our Internet uplink isn't saturated at peak times.
• de-prioritise third-party user bandwidth.
• perform antivirus and OS checks.
• offer the ability to install AV software and upgrades.
• block P2P connections unless the device passes posture validation.
• use a DMZ for all of our BYOD devices

There are some design decisions that add significant cost and will need to be validated by strategy and backed by funding.  It may also dictate which vendor solution you choose.

Some requirements will conflict or be unachievable within budgets.  So be sure to set expectations on which requirements are more expensive to deliver than others.  Media based services will almost always add complexity and cost to the design.

A great example of an awkward media solution is Apple TV - execs want this in meeting rooms.  You'll need to support the Bonjour protocol which is peer-to-peer multicast via a L3 gateway.  Not all vendors can support this, and it can be a challenge for security and infrastructure design.

In the current environment some devices are more enterprise ready than others.  A wide variety of users and devices will mean different levels of authorisation and policing.   So the BYOD strategy may need to include several service types which are dictated by the security capabilities of the device (or the MDM vendor).  Consider that creating a 'preferred device' service for Apple iOS devices will potentially cause discontent with the owners of other devices who can't subscribe to the same level of service.

The message for part 1 of Building BYOD…

Spend some time gathering all of the requirements.  Understand what the possibilities are and which services and device types you want to support.

Part 2 - Secure Design
http://uk-wireless.blogspot.co.uk/2012/07/building-byod-pt-2-secure-design.html