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

2 comments:

  1. MS-CHAPv2 is an even worse choice for authentication than your (excellent) article suggests - it seems that MS-CHAPv2 has been rendered completely useless as a 'strong' authentication method:

    https://www.cloudcracker.com/blog/2012/07/29/cracking-ms-chap-v2/

    The crack still requires some effort, and is certainly not (yet) within the realms of a 'drive-by' attacker, but anything secured with MS-CHAPv2 should be considered insecure, and certainly anyone considering implementing BYOD if they haven't already done so should not consider MC-CHAPv2.

    ReplyDelete
  2. There is a fantastic riposte from Andy vonNagy that discusses why the MS-CHAPv2 announcement is not as dramatic as it sounds for use within WLAN.
    http://revolutionwifi.blogspot.co.uk/2012/07/is-wpa2-security-broken-due-to-defcon.html

    It's similar story with the SCEP shared secret vulnerability that has recently been announced. It really depends on the usage. But backs the theory that your PKI should be third-party rather than corporate. Check this excellent blog.
    http://blogs.gartner.com/mark-diodati/2012/07/02/mobile-device-certificate-enrollment-are-you-vulnerable/

    ReplyDelete