Enterprise Mobile

It is a well know fact that a lot of enteprise IT pros require data encryption for mobile devices.  The Windows Mobile operating system has included support for the Data Protection API (DPAPI) since Windows Mobile 2003.  And DPAPI forms the basis for Windows Mobile file encryption used with removable storage cards (Windows Mobile 6.0) and main memory (Windows Mobile 6.1). 

DPAPI provides easy-to-use functions for encryption and decryption.  A number of applications use DPAPI.  The thing that makes DPAPI easy to use for developers is that they don’t have to wite all the key generation and key management code that typically goes with any encryption solution.  DPAPI uses a master key that is stored in the memory of the device.  When an application calls DPAPI, the same master key is used to generate symmetric keys for all encryption and decryption operations.  In this way, the application does not have to generate or manage the encryption key used.  For a thorough description of DPAPI see the MSDN article covering Windows Data Protection

Of course, this begs the question, “How is the master key protected?”  The master key is encrypted itself at the time it is generated.  And, it is decrypted at system boot time.  It must be decrypted for use during boot in case an encrypted file is loaded during the boot process. The key used to decrypt the master key is derived from a password and used during boot.  In Windows Mobile, there are 2 master keys, the “user” master key and the “system” master key.  The “system” master key is encrypted using a key derived from the system “password” which is a mixture of system information.  The “user” master key is typically derived from a user password. 

The “user” master key is considered more secure then the “system” master key because the entropy used to encrypt it includes information only the user knows (i.e., their password).  The “system” master key is more flexible though because the system does not need to go get input from the user.

The “user” master key on WM 6.1 is derived from the Windows Mobile device lock PIN or password that is entered by the user during device boot.  Therefore, when you enable encryption on a device, the user must configure a PIN/Password, if not already configured. 

Note that the encryption of data written to storage cards in Windows Mobile 6.0 and later also uses DPAPI, but with the “system” master key rather then the “user” master key.  This is a lot less of an issue for removable storage card encryption then for main memory file encryption.  The primary attack on the “system” master key requires access to the system used to create it and typically,the attack on the removable storage card is mounted from a different computer that the lost or stolen removable storage card is inserted into.

btw, the default encryption algorithm used since Windows Mobile 6.0 for DPAPI is AES-128.  Prior to Windows Mobile 6.0, DPAPI utilized RC4.

Dave Field, CISSP, MCP
Device Management and Security Architect
Enterprise Mobile, Inc.

Here is the follow-up installment #2 on device emulator configuration.  You may want to read installment #1 first.

I often need to test our code across various versions and SKUs of Windows Mobile.  For instance, I need to test one feature across WM 5.0 Smartphone, WM 5.0 Pocket PC Phone Edition, WM 6.0 Standard, WM 6.0 Professional and, of course, the newer WM 6.1 SKUs.

When testing, you often want to use a hard/cold booted device for the most reproducible results.  Cold booting and then reconfiguring a bunch of devices is super time consuming.  Even if using the device emulator, configuration can be time consuming.

Another important issue is network availability.  Much of my testing requires a network connection for client/server applications.  I used to connect my emulators using Desktop Passthrough via Desktop ActiveSync or Windows Mobile Device Center on Vista.  This setup invariably led to the following problems:

1. Time spent in setup of the work/internet connection manager settings every time I reconnected
2. ActiveSync automatically sets your HTTP proxy which is sometimes not desirable. Unfortunately, the method used by activesync to gather the proxy and proxy port from the desktop can lead to errors. For instance, our outbound proxy operates on port 8080. But, activesync configures the device to use port 80 which then causes “work” connections to internet web sites to fail.
3. You can only connect one emulator at a time to activesync. If you want to test across multiple emulators simultaneously, you cannot use ActiveSync.
4. ActiveSync Desktop passthrough only supports http/https traffic. If you want to use other ports/apps, it won’t work. For instance, I’ve been testing an ICMP ping application and cannot use it through desktop activesync.

These issues can be solved by utilizing the built-in NE2000 NDIS network adapter that comes with the device emulator. Here is a set of steps that I use for setup.  After you finish setup, you can save the device emulator state and when attempting a new test case, you simply close and re-open the emulator for full cold boot with configuration intact.

Here is how I go about configuring the emulator to meet my testing requirements.

First, if you’ve ever saved state on the device emulator image before, right-click the image in the Device Emulator Manager and choose “clear save state”.  This provides a true default, factory-reset image as your starting point.  There is an option in the emulator’s file menu for cold reset, but it does not take the device back to a truly “clean” state.

Next, in the Device Emulator window, open the File menu and select “configure”. 

In the “General” tab, you can configure a “Shared Folder”.  I like to share a folder located on my desktop to the device emulator by configuring the “shared folder” setting.  Once configured, you can open desktop files in the emulator by browsing the “storage card” volume in file explorer on the device emulator.  If using multiple emulators, you can set them to all use the same shared folder.  This allows you to copy files into the desktop folder and then open the identical file on all emulators.  For instance, you could copy CAB Provisioning Files (.CPF) to the desktop shared folder and execute them from the device emulator’s file explorer to easily configure the device.

In the “Network” tab, you can setup your emulated NE2000 adapter.  Just select the checkbox for “Enable NE2000 PCMCIA network adapter and bind to:” and select “Connected Network Card”.  The NE2000 will bind to the first network adapter it finds on the desktop computer after you click OK on the “Emulator Properties” checkbox.

You may find that you still can’t connect to known servers using the device emulator’s Mobile IE browser.  That is likely due to work/internet settings.  Here is what you do:

1. Open settings
2. Open connections:
   • On PPC, click the “Connections”
   • On Smartphone, just open the “Connections” setting menu item.
3. On PPC emulators, route “Network Cards” to the correct network: “work” or “internet”. If your desktop is connected to a private/work network with a firewall that requires proxying to the internet, set “Network Cards” to point to “Work”. NOTE: Smartphones are hardcoded such that the NE2000 adapter always routes to “work”. You can see this by by opening the “menu” and selecting “Adanced” on the “Connections” menu. You won’t be able to change it to route to “internet”. If you don’t configure a proxy setting, it won’t make a difference.
4. If you selected “work”, then you likely need to configure a proxy. Open “Connections” again as you did in step 2 above.
   • On PPC, open “Connections” and click the hyperlink for “Edit my proxy server”
   • On Smartphone, open “Proxy” and click “Add” off of the Proxy “menu”
5. Test your connection by opening both an internet web site and a private/work network website in Mobile IE. You may need to change your proxy and/or network card routing configurations.

At this point, you may want to configure some of the following:

• Root and intermediate certificates
• Mobile IE Favorites
• Application installations

After you’ve finished creating your base image configuration, click the “File” menu in the device emulator windows and select “Save State and Exit”.  After the save process is finished, reopen the same emulator image and you’ll find that its configured and ready for your first test case!  After you’ve completed a test case, close the emulator, but do NOT save the emulator image or it will overwrite your carefully created image.  Re-open the image and you’ll find that you are right back to your base image configuration and ready for your next test case.

If you are using multiple device emulator instances to test a client/server application, you can have them all open and connected at once to run the test case simultaneously.

If you choose to use activesync, then use it after you’ve created and saved your base image, if possible.

Hope this helps!

Dave Field, CISSP, MCP
Device Management and Security Architect
Enterprise Mobile, Inc.

The following is the first of 2 installments that describe how I use Windows Mobile Device Emulators.  This installment covers setup and basic use while the second installment covers configuration.

A lot of people test and demo Windows Mobile devices using actual devices.  This works fine for most scenarios.  However, there are some distinct advantages to using device emulators:

·         The device emulators are free as they come with the Windows Mobile SDKs.

·         If you use a device emulator for your demo, you don’t need to use an Elmo overhead projector to show what’s happening on the device.

·         You can pre-configure a device emulator, save the pre-configured state and quickly “reset” the emulator back to the pre-configured state.  This is a real time saver for both demoing and testing.

·         You can test across multiple versions of the Windows Mobile Operating System simultaneously on one PC

If I’ve convinced you that the device emulator is worth setting up, follow these steps.

First, install the various Windows Mobile SDKs which include the device emulator images you will need to use:

·         WM 5.0 Emulators:  PPC and  Smartphone

·        MSFP Emulators - Note: This site allows download of the stand alone device emulator manager (v1emulator.zip) as well as the MSFP emulator images (efp.msi)

·        WM 6.0 Emulators

·        WM 6.1 Emulators

Next, you will need the Device Emulator Manager which comes integrated in Visual Studio (go to Tools/”Device Emulator Manager”).  If you don’t have Visual Studio, you can download the standalone Device Emulator Manager from the same download location as the MSFP Emulators.

Now, open the Device Emulator Manager which will show all the emulator images you’ve installed (see below). 

Note that the MSFP images do not automatically show up in the device emulator manager like all of the other emulator images.  MSFP images only show up after they are opened from the start menu (start/” Microsoft Windows Mobile 5.0 MSFP Emulator Images”).  Once the MSFP image is opened, it shows up in the “other” branch as an image GUID.  You may need to click the “refresh” button after the image is open to see it as shown below.

Now, open the image by “connecting” to it.  Right-click the image and select “connect”.  This will open the emulator in it’s own window.  Notice that you can open many emulators all it once by repeating the connect process for all of them.

You can connect the emulator to desktop activesync or WMDC if you want.  I recommend avoiding it, if possible.  ActiveSync connections can muck with work/internet settings and will automatically configure a proxy setting which may not be correct.  For instance, our proxy uses an outbound port of 8080 for HTTP traffic and ActiveSync configures use of port 80 which does not work.  But, there are some tasks that require use of ActiveSync.  To do it, you need to set Connection Settings to support a “DMA” connection type:To initiate the activesync connection, right-click on the image in the device emulator manager and select “cradle”.  Check back for installment 2 that will discuss the device emulator configuration that I use for testing.To initiate the activesync connection, right-click on the image in the device emulator manager and select “cradle”.Check back for installment 2 that will discuss the device emulator configuration that I use for testing

Dave Field, CISSP, MCP

Device Managment and Security Architect

Enterprise Mobile, Inc.

Another great article in the current issue of Smartphone/PocketPC Magazine from my colleague Patrick Salmon. Check it out here:

http://www.pocketpcmag.com/cms/_archives/Jun08/SystemCenterDevice

Good round-up of knowledge skills and necessary to get started with SCMDM. Provides an excellent overview of the technology and why it is important as well!

Marco Nielsen
mnielsen@enterprisemobile.com

When installing System Center Mobile Device Manager (aka MDM) in a customer environment recently, I encountered a scenario where VPN connectivity worked on all but one of the mobile networks we tested. Here’s a recap of the challenges I encountered, and the eventual solution.
Summary
After installing all MDM components, we were able to successfully enroll and connect two T-mobile devices without any problems. Next, we tried connecting AT&T devices (using the recommended isp.cingular APN), and the tunnel would come up but the device could not access any internal systems. Policies would get pushed down to T-mobile (or even WiFi) connected devices flawlessly, yet isp.cingular would always fail. This happened consistently across a variety of devices, SIMs and regions of the country. We were also able to take the same device, SIM and APN and connect fine to our MDM lab here at Enterprise Mobile.
Troubleshooting
To troubleshoot this issue, we tried quite a few different tests. For each test, we would open up IE Mobile on the device and try to access both the FQDN and IP of the Device Management (DM) server. Keep in mind that the DM service typically run on port 8443, so to properly test connectivity, you need to access a URL in the format of https://<IP or FQDN>:8443/. When connectivity is working properly, you will get prompted to select a client certificate for authentication with the DM server.

The tests we attempted were:

• Enroll and connect a device using a T-Mobile SIM, then swapping in the AT&T SIM (failed).
• Run network captures on devices connected to both isp.cingular and wap.voicestream and compare the results. Behavior looked identical: the tunnel came up fine, and DNS requests were sent out over the internal network. However, the isp.cingular device never received the query response, while the wap.voicestream device did.
• Run network captures on the firewall between the Gateway (GW) and DC/DM servers. DNS requests from devices made it in/out, but never made it back to isp.cingular devices.
• Verified that the SIMs were using were properly provisioned for isp.cingular.
• Through all this, wap.cingular worked fine (although that is not recommended) while isp.cingular continued to fail.

Solution
After speaking with a number of people at EM and MS regarding this issue, we discovered that the MDM mobile VPN operates over slightly different ports depending on whether the client network uses NAT. When there is no NAT in use, Protocol 50 is used for encapsulation of data in the VPN (IPsec) tunnel. However, when NAT is in use, UDP 4500 is used for this encapsulation instead.

The fact that data was flowing over the tunnel fine for some connections but not other likely indicated a problem with connectivity over either Protocol 50 or UDP 4500 from the Internet to the GW. As it turns out, all of the networks were testing over used NAT, with the exception of isp.cingular. That narrowed our focus down to Protocol 50.

Now that we knew the likely issue was with Protocol 50, we focused on the firewall (a Sidewinder 1150) that was between the GW server and the internet. We eventually found the following entries in the FW logs:

Apr 4 14:35:46 192.168.122.10 auditd: date="Apr 4 18:35:46 2008 GMT",
fac=f_kern_ipfilt,area=a_general_area,type=t_info,pri=p_minor,pid=0,ruid=0,euid=0,pgid=0,logid=0,cmd=kernel,domain=Abot,edomain=Abot,hostname=<fw>,
rule_name=<ESP-rule-name>,srcip=<client-IP>,dstip=<GW-IP>,protocolname=esp,information=”=IP Filter: 1 packets successfully forwarded by rule”
Apr 4 14:35:46 192.168.122.10 auditd: date="Apr 4 18:35:46 2008 GMT"
,fac=f_kernel,area=a_nil_area,type=t_netprobe,pri=p_minor,hostname=<FW>,event=IPv4 netprobe,srcip=<GW-IP>,dstip=<client-IP>,
protocol=50,srcburb=<srcnet>,interface=vlan2,reason=”An IPv4 packet was received for a protocol not supported over IPv4.”

It turns out that the FW was allowing Protocol 50 inbound, but blocking it on the way back out. The rule that was defined for this traffic specified bi-directional, but the FW still blocked the outbound.

The final solution was to change the existing rule to inbound, and create a separate IP filter rule for outbound Protocol 50. With that change, outbound traffic worked, and isp.cingular connected devices started behaving normally.

Keep in mind that above all this, some mobile operator APNs may not work simply because the operator has blocked certain ports (such as UDP 500/4500). Please coordinate with your preferred MO(s) to ensure that you are using an APN that is appropriate for use with MDM, and that all of your SIMs are provisioned accordingly.

Chris Saint-Amant
Mobile LOB Architect

A recurring question I get is how to test and demo the software distribution capabilities of MDM.

People generally run into errors with importing test CAB files because the DM does not trust the signature the CAB was signed with - or the CAB is simply unsigned. First thing to note is the software distribution server can only import signed CAB files. You cannot disable this feature (as of this writing anyway.) The root certs of the certificate that signed the cab file must be in the Trusted Publisher store on the DM server. In most cases you will have to manually put it there.

If you have several unsigned apps, create a cert from your MDM CA and use that for signing all the CABs. The steps for how to do that are in a CAB Signing document on the Connect site or came with your MDM product documentation.

If you would like to do a quick test without going through the self signing cert process, you can deploy a Microsoft signed CAB like live search. You can download the cab here:

http://mobile.search.live.com/client/download_manual.aspx

You will need to prep your DM server to trust the certs and CA used to sign the live search cab. Here’s the steps to do that on your DM server.

  1.)   Download and import the Verisign / Microsoft M2M root certs from here:          

http://blogs.msdn.com/hegenderfer/attachment/3272332.ashx

2.)   Extract the contents to a temporary folder.

3.)   Start->Run-> MMC

4.)   Add / Remove Snap In - Choose Certificates MMC (Not certificate templates or certificate authority)

5.)   It will prompt for User, Service or Computer - choose computer.

6.)   Right click Trusted Root Certs ->All Tasks -> Import and import all of the .cer files extracted in step 2.

7.)   Right click on the LiveSearchWM5.cab file and choose properties.

8.)   Choose Digital Signatures

9.)   Click on Microsoft Corporation

10.)  Click Details Button

11.)  Click Details TAB

12.)  Click Copy to File… button.

13.)  Click Next twice in the Certificate Export Wizard

14.)  Enter c:\Microsoft.cer as the file name and click next

15.)  Click Finish

16.)  Back to the MMC Right click Trusted Publishers ->All Tasks -> Import and import the file c:\Microsoft.cer

17.)  Run the SW package import wizard and you should see success.

Once the CAB is imported you can simply follow the steps in the operations guide for how to deploy the application to your devices using the MDM software deployment MMC.

The Windows Mobile device management platform supports two different Open Mobile Alliance (OMA) standards:  OMA Client Provisioning (OMA CP) and OMA Device Management (OMA DM).  By the say, OMA CP is the new name for WAP Provisioning.  So, when you see Windows Mobile configuration XML with the root node of <wap-provisioningdoc>, you know you are using OMA CP.

Because Windows Mobile supports both OMA CP and OMA DM, you’ll find that MSDN documentation for most Windows Mobile Configuration Service Providers will include information on configuration XML for both standards.  OMA DM is suppose to be the new, improved standard (and it is in many ways).  So, you may wonder why OMA CP support is still included. 

As with most wireless-related standards and protocols, ubiquitous deployment and use of OMA DM has been slow.  OMA CP is still widely used.  Of course, the improvements inherent to OMA DM will drive eventual OMA DM ubiquity, but for now, OMA CP still rules the roost.

But, from a Windows Mobile developer point of view, there is another reason why OMA DM is slow to take hold.  The Windows Mobile device management platform does not come with  an OMA DM API.  The only way to take advantage of Windows Mobile OMA DM functionality is to bootstrap an OMA DM server to the device and interact with the platform through a client/server connection.

In comparison, the Windows Mobile device management platform provides much richer interfaces to configure the device using OMA CP.  There is nice API, DMProcessConfigXML (this is the native API, managed .NET CF API is called ProcessConfigXML in Microsoft.WindowsMobile.Configuration) .  You can also configure the device via Remote API (RAPI) that is exposed on desktop PCs running ActiveSync or Vista Windows Mobile Device Center (WMDC).  Of course, OMA CP can be configured via a WAP provisioning server for the client/server connection functionality.  But, for device developers, we need a client-side API which does not exist for OMA DM on Windows Mobile.

Why do we need a client-side API for OMA DM?  The main reason is to build a value-added device management solution for customers that want more then what you can get out-of-the-box with the Windows Mobile device management platform. 

For instance, a client application can save bandwidth and improve performance by adding smart query logic to device management transactions.  Otherwise, you’d need to offload all the logic to the server.  An example might be that a client can detect a new Bluetooth profile registration and allow or disallow its use based on a pre-configured policy.  Without this, the information must be uploaded to the server, processed by an admin or some server-side application and a new policy is provisioned to the device’s networkpolicy CSP.  That’s just one example though.

Another reason to build a client application for device management is to add new device management features to those provided out-of-the-box.  If you use a device with built in GPS, RFID reader, etc., you may want to manage these devices and their requisite applications as well.  And, if you want to support device management across multiple hardware and operating system platforms, you’ll probably end up opting to build a device management client.

You may be thinking that this is all a lot of whining though because the Windows Mobile device management platform still makes OMA CP configuration accessible to applications.  But, consider that in Windows Mobile 6.1, most all of the new software management Configuration Service Providers are OMA DM only with no ability to manage them via OMA CP.  This means that a Windows Mobile Device Management developer will need to use an OMA DM server or a proprietary client application to leverage the new, cool, built-in Configuration Service Providers that manage software and ROM update installations. 

In conclusion, the call to action is for Microsoft to provide and public, documented API for applications to interface with Windows Mobile OMA DM components just like OMA CP.  Perhaps DMProcessConfigXML() can be extended to support both OMA DM and OMA CP XML input.

Dave Field, CISSP, MCP

Device Managment and Security Architect

Enterprise Mobile, Inc.

Hello,

Here is a little issue that I researched this week and I thought I’d share it on the blog.

PROBLEM:  When accessing a website that is secured to use an NTLM authenticated password, the “Save Password” option does not work on Windows Mobile Pocket PCs and Smartphones.

Here are detailed steps that outline how to reproduce this problem using a Motorola/Symbol MC70 Pocket PC.  Note that the test device was running Windows Mobile 5.0 AKU3.

1.       Perform a “clean” reboot of the device which is a cold boot that resets all storage volumes on the device to factory defaults.

2.       Configure a website connected to an Active Directory domain to use password authentication.  During testing, you’ll need access to IIS Admin. 

a.       Start out using basic authentication.  In properties for the website, open the “Directory Securty” tab, click the “Edit” button for “Authentication and access control” and check the box for “Basic authentication”

b.      Use of HTTPS/SSL is irrelevant to the test.  However, basic should not be used without SSL because the basic password is sent in clear text.

3.       From the device, open the website in the Mobile IE browser.  You will be prompted for the password.  Note:  “Realm” is included in the Basic authentication dialog box.  For NTLM authentication, “domain” input is required.

4.       Enter your domain\username and your password.  Make sure to check the “Save Password” box.  Then tap “OK”.

5.       Confirm that your password-secured site renders in the Mobile IE browser.

6.       At this point, if you were to refresh the page or even browse to a couple sites before revisting the site, you would not be asked for the password again.  This is because the website page that was opened after authentication is cached.  By exiting out of the browser session and re-opening the page, authentication occurs again.  You can exist the browser session by warm resetting.  But, it is easier to stop and restart the “internet explorer” process as follows: 

a.       On the device, go to Settings/System tab/Memory/Running Programs tab.  S

b.      elect “Internet Explorer” from the “Running Programs List:”

c.       Tap the “Stop” button.  This stops the browser process.

7.       Re-open the Mobile IE browser on the device and browse to the website again.  You should find that you do not need to enter the credentials this time for the web site because they are cached. 

CONCLUSION:  Save Password works with “Basic Auth”

8.       Close the browser session again as described above in step #6

9.       In IIS admin, change the authentication for your website from basic to NTLM:

a.       Uncheck basic and check the box for “Integrated Windows Authentication” which is NTLM.

b.      Stop and restart the website to ensure the authentication change is implemented

10.   On the device, confirm that the “internet explorer” process is not running.  If it is, stop the process.

11.   Open Mobile IE and browse the website again.  This time, you’ll see the following authentication dialog for NTLM (Windows Integrated) authentication. You’ll see that username and domain are cached from the previous use of your credentials for basic authentication.  However, the previously cached password is not re-used.

12.   Enter your password and be sure to check the “save password” box prior to tapping the “OK” button.

13.   Confirm that your password-secured site renders in the Mobile IE browser.

14.   Close the browser session again as described above in step #6

15.   Now re-open the website .

16.   You will see the same authentication dialog that you saw in step# 11 above.

CONCLUSION:  By default, the “Save Password” option exposed in the Mobile IE authentication dialog does not save the password for NTLM authentication cases.

WHY DOES THIS HAPPEN?:  Underlying Mobile IE is the use of the Windows Internet API (wininet) which is a set of core code inherited from desktop windows.  You may have noticed that in order to cache NTLM with desktop IE, you need to configure the website to be an “intranet” zone website.  Furthermore, you have to set your security settings to use user authentication logon settings to use automatic logon only for intranet zone” or “Automatic Logon for user name and password”.  Once the user of desktop IE has entered and saved their password for the “intranet” website one time, they no longer need to enter it on subsequent use.  Mobile IE encounters the same problem as desktop IE, but in Windows Mobile IE, there is no configuration UI to allow the user to make these changes.

SOLUTION:  You can add the website to the list of intranet sites by hacking the registry on the device.  To configure http://www.yoursite.com/ and https://www.yoursite.com/ as “intranet” websites and therefore eligible for NTLM password caching:

1. Add the registry key:  HKLM\Software\Microsoft\Windows\CurrentVersion\Internet settings\ZoneMap\domains\yoursite.com\www
2. Under this new key add 2 values: “http” and “https”
3. Set each of the 2 values to “1″

NOTES:

• The website domain name prefix (eg, “www”) is configured as a sub-key of the domain name (eg, “yoursite.com”).
• You need to configure each URI scheme (http, https, ftp, etc.) that may be used for the website. Each different URI scheme will require a separate instance of the cached password
• By setting value=”1″ for the URI scheme, you are configuring that full URI as a site in the “intranet” zone. Here is the value associated with all zones: 0 My Computer, 1 Local Intranet Zone, 2 Trusted sites Zone, 3 Internet Zone, 4 Restricted Sites Zone.

• For a full discussion of all security zone registry settings see: http://support.microsoft.com/kb/182569

• There are a number of registry editors for Windows Mobile devices that you can download and use. However, you can use WAP Provisioning XML to query and write to the registry via the registry configuration service provider. You can use a tool such as rapiconfig to implement WAP provisioning XML on Windows Mobile devices. The rapiconfig tool is available in the Windows Mobile Software Development Kits.

Dave Field, CISSP, MCP

Device Managment and Security Architect

Enterprise Mobile, Inc.