I guess the tech blog bug has me in its inescapable web. I posted a nice 2000 words on Boxer for iOS and people think I might actually not be just a loud mouth from Boston so hurray for me.

First off, because I’m not that pretentious and think everyone knows all these silly acronyms. DLP means “Data Loss Prevention” or in other words don’t let my silly users send company data to non-company sources and potentially causing REALLY bad stuff to happen. There have been reports over the years of SEC fines, lawsuits, and many other terrible things to occur because a company skirted their DLP responsibilities. I mean just look at half of the major exploits over the last decade and most of them weren’t because people were being awesome stewards of security. Feel free to infer from that however you wish.

DLP requires some actual critical thinking because it’s not cut and dry. It’s not, hey I made sure they can’t open attachments in anything! It’s also not hey they can’t save stuff to DropBox! It is SO much more. So let’s get down to this fun mental exercise. First let’s cover the areas of attack. This document focuses on iOS because from my estimation in the business space I just don’t trust Android at this point. We’ll give them credit as Android OS 7 is a HUGE improvement in security but that’s just not my preference or recommendation for truly sensitive information. So the areas are:

• Native Email and its attachments
• Microsoft Apps
• Non-Microsoft Apps aka Managed Destinations
• Managed Email Domains and Web Domains
• AirDrop
• Handoff
• Cloud Providers
• The “Unknown”

Native Email and its lovely attachments

So similarly to many of the women I have dated in my life, email is quite “attached” to the files it comes with. Yeah I know that’s terrible but still… email and their attachments go side-by-side. Anyways, the real keys to limiting DLP with the native mail application is two parts (1) Prevent Moving Messages/Prevent Mail Drop and (2) Blocking those attachments from being in unmanaged destinations.

Preventing Moving Messages

So this is pretty simple, this feature will give you two things. It stops people from moving messages from one account to another AND it stops them from changing who the sender is of an email. A good real-life example is:

1. User copies and pastes some corporate data into a new email
2. User changes the from: to their personal account
3. DLP FAIL!

It’s amazing how many companies overlook this feature because its not part of the standard restrictions payload, but it works like a charm if you do it right.

Prevent Mail Drop

Like so many features that Apple introduces (YES I’m talking to YOU Handoff) they are so amazing for consumers but such a unabashed nightmare for enterprises. So what is this mail drop you speak of?!

Really simple, you can directly attach files/save files back to iCloud Drive and other cloud services. This really epitomizes one of the bad things that we must prevent in DLP. It’s similar to an issue that came out in iOS 9 which they have fixed which let you export most files to PDF and creating another DLP nightmare. That’s why I CANNOT stress enough that companies should invest in mobility and especially strong testers because if you aren’t good then you definitely missed the export to PDF into iBooks. Certainly not the best feature ever for us mobility folks.

Blocking the Opening of Managed Files in Unmanaged Destinations

Yes, the word managed is absolutely terrible and no one likes it! It makes your users go EEEEEEEEKKK!!!!! This is what my users do when I say the word managed

Anyways, yeah I’m a nerd..moving on! Any application that is installed via MDM is considered to be managed/trusted. Here’s the kicker that no one tells you. They added a neat MDM feature where if someone installed an app from the App Store, that it would prompt the user to take management of the application (happens automatically if its a Corp device). The big key is that this is NOT automatic. I used that word purposefully. When you publish an app in a MDM app store, you have two options (1) automatic deployment or (2) on-demand deployment. My hope is you like having a job and don’t want people to line up at your desk with pitchforks and do mostly on-demand deployment, which means when someone enrolls they get a VERY limited amount of automatically-deployed apps like the agent app and VPN apps. The only apps that will automatically prompt users to take over management are automatically-deployed apps. So…i’m sick of using the word automatically in this paragraph. I just used it roughly 6 times…sorry! That means you need to be proactive and make sure the apps that need to be managed ARE managed otherwise you are asking for issues.

This is important because when you leverage the restriction: Allow Managed Documents (attachments in the mail application or part of managed-web domains (more on that later!) )in Managed Destinations you will rely heavily on that concept. So let’s summarize:

• DISABLE allow managed documents in unmanaged destinations
• Make sure the Office Apps or whatever apps you use to open company docs are MANAGED so you don’t cause unhappy users
• MONITOR the status of user’s applications for any “weird” behavior (i.e. make sure Microsoft Apps say managed and not user-installed)
• SET EXPECTATIONS for your users about the lovely prompts that will say “Allow X Company to manage X application)
• RE-EVALUATE your App Store and make sure only apps that you TRUST are published.
• UNDERSTAND what the apps in your app store can actually do and don’t just publish stuff all over the place. You OWN the risk so OWN the data stewardness of it.

I promise if you do those things you will “mostly” be okay with your managed document and application ecosystem. We will talk more about the “weird stuff” you see with Microsoft Apps in the next section in this blog post.

Managing Microsoft Apps

Some of you may have attended my talk at AirWatch Connect 2016 that I gave on navigating the Microsoft minefield of Mobile Application Management. The best thing that has ever happened to me was BlackBerry giving me the chance to work with their Premiere Support team working with some of the best government teams that we have. The second best thing was Microsoft opening up MAM controls for Office Apps. I know many of you were being attacked with the “When are we moving to Intune?!” and “We need to control these apps!” This allowed me and many others stick with their current mobile strategy instead of turning it on its head to ensure that Office Apps can be properly secured.

So, this is a multi-part strategy that starts with pushing the UPN to the application via your MDM app store. You deployIntuneMAMUPN application keys with a value of the user’s email address (typically). That’s the easy part! The harder part requires that you own Enterprise Mobility Suite licenses with O365.

One thing that I learned recently is WHAT the app key actually does. The app key gives you these features:

• The SDK will treat the app as managed even if its missing policies
• Stops the user from logging in as a different user in the organization
• Required to ensure that the Open-In data is encrypted
• Ensures that the app cannot send data to non-policy managed apps

How MAM without MDM Works

First you log into the Azure Portaland access the “Intune App Protection” section. You can essentially apply application management policies that are tied to your user account. “Theoretically” it will apply policies to your application after you login which will make you “reboot” the app aka the app will be force closed and you need to re-open it. The images look something like this. I say it like that because they change the UX aspect of MAM constantly so you never know.

The most common features that people leverage with MAM policies are:

• Prevent Save As
• Choose what Cloud Service Providers you can save to (OneDrive for Business, Sharepoint, Local Storage)
• Prevent iTunes backup
• Restrict Cut, Copy, and Paste
• Jailbreak/Root Protection
• Require PIN
• How long you can be offline before application wipe

You can read about other policies and general FAQ hereas that is not my main focus of this. The most important thing to know is if you want the policies to ACTUALLY work you should have people install OneDrive FIRST and that will receive the policy pretty easily. Then you have them open a doc from each app they want to use from OneDrive into that other app to ensure the policy propagates to the other apps as it is not always seamless.

You will also see inconsistent experiences on some applications if they are NOT both managed applications AND MAM-enrolled, such as you can’t use the export page to PDF function in OneNote. The other big thing to know is that Microsoft’s policies are heavily focused on “Multi-Identity” which is basically a BYOD approach to management. In other words, someone can use the application from a personal perspective without being impacted by the MAM policies. The huge BUT with this is it is not available for OneNote. This creates a major problem when someone can no longer copy and paste or move pages with their personal OneNote. I strongly urge you to evaluate the risk to your organization and tread carefully with how you deliver this message to your end users. After all, they’re the reason you are employed 🙂

A few last notes on MAM policies to be aware of for fun:

• Microsoft Apps are not required to support MAM. Microsoft creates the Intune SDK and makes it available to the individual application teams at Microsoft. It’s up to them if they decide to adopt it or not. For example, the RDP team chose not to implement it so you cannot restrict copy/paste between a corporate device and personal RDP session. Also, you cannot stop someone from saving passwords on a mobile device’s RDP application.
• Reporting is mostly best effort. Sorry friends! It’s not exact and I say trust but verify. Often it is impossible to differential if someone has multiple iPads and sometimes the reporting is inaccurate.
• Check the portal frequently as they often make updates/changes that you have no idea about until you see it
• They have new reports that show you what users of a specific app are unprotected. It’s a decent resource so always use it.

Managed Applications

So now the fun begins! Let’s forget the buzz words. Why do we publish apps to an app store outside of the obvious?

• Any app installed from the App Catalog is removed on unenrollment
• You can use Per-App VPN YAY!
• You can deliver managed app keys for DLP/Configuration
• Force application management
• Create a trust between the mail application and a sub-set of apps

The important stuff is managed apps can be used to open your mail/trusted web documents into AND you can deliver DLP (maybe) to certain applications. I strongly urge everyone to look at the AppConfig Community which is this great collaboration to deliver specialized configurations and controls to public applications. I know that’s a hot mess of words that human being don’t comprehend. I like examples so let me provide a good one.

Salesforce supports keys to pre-configure the environment information and the ability to block copy/paste of Salesforce content. It looks like this:

Many other great apps support these keys like WorkDay, Symphony, SAP, and many more. I’ve personally helped a few companies implement these keys in their applications. The reality is it doesn’t take much effort and you just need to “motivate” them to do it. The technical explanation is that a MDM server can push down “stuff” into NSUserDefaults for remote configuration. Feel free to reach out to me if you need help implementing these keys as it provides SUCH a huge benefit to users.

Managed Email Domains

This is a pretty simple concept. You can use your MDM to whitelist domains. Any email sent to a domain outside of this list is displayed with red text. It’s simply a visual indicator that reminds you that you might want to make sure you aren’t sending confidential information.

Managed Web Domains

Managed web domains are fairly similar to email domains conceptually. You set a list of web domains that are treated as managed destinations. I know that’s word vomit. Basically, you set your internal domains as trusted so any documents opened from them can be opened by your trusted apps. One area that people often overlook are their HR apps. You want to make sure you whitelist your SaaS applications so you can ensure PII is not handled poorly or insecurely.

AirDrop

I was mentioning AirDrop earlier as one of these gorgeous consumer features that give us tremendous headaches. You basically use AirDrop to share documents in many ways, such as sharing from iOS device to Mac, iOS device to iOS device, etc. You have two ways of limiting this. If you are lucky enough to be a full corp environment, you can disable AirDrop altogether which I am totally onboard with doing. The other “more realistic” option is to enforce AirDrop as an unmanaged drop destination aka ” GOOD LUCK STEALING MY CORPORATE DATA!”

This is really only half the battle. I think one of the major DLP risks that we have today is we don’t make sure our Mac OS X policy matches our iOS policy. Sometimes some vital content can be exfiltrated because we aren’t securing our Macs are solidly as our iOS devices. Remember a laptop is a mobile device now too folks!

Handoff

This is not going to be a popular sentiment, but TURN OFF HANDOFF in enterprise environments. Contrary to popular belief, you can survive without handoff. It’s not the cure for cancer, it’s not a panacea, it’s not the greatest thing ever! Sure it’s really cool, but it can also create risk. You don’t want people to be able to do dangerous things with handoff. Some of the things you can do are:

• Universal Clipboard
• Use your watch to unlock your Mac
• Take calls/SMS on your Mac
• Start and resume tasks between iOS and Mac on several stock Apple products

The clipboard is the most dangerous one as you can copy and paste sensitive information and move it to unmanaged assets, which I don’t have to explain why that is bad.

Cloud Providers

I’m not going to go down the rabbit hole, but moreso just go down it a bit. We can only do so much when it comes to Cloud Providers. Here’s a few ways of solving issues with cloud storage:

• Always-On VPN (Good Luck selling that one)
• CASB solutions like Netskope or Skyhigh
• Using a Cloud Proxy with Corporate Devices to ensure all content goes through your proxy and using rules to block consumer cloud services.
• Following my earlier recommendations on securing your applications and ensuring that you are eliminating as many risks as possible.

The biggest problem isn’t the cloud providers on their own, but that many of the mobile applications are integrating with them because it gives a great user experience. Even Microsoft is now opening up their applications to work with other cloud products. We can eliminate the majority of the risks but without a CASB solution you will always have concerns with users copying data, taking screenshots, or being super creative. If someone wants to copy information bad enough, they will find a way. Sometimes its more about making it SO inconvenient for them that they reconsider it. I think we all know that nothing is truly infallible.

Here’s a news flash to non-mobile engineers, mobility gives us an amusement park where we can be creative and brilliant. We have the ability to look at what Apple or Google give us to play with and find a way to solve something. I have over the years came up with some absolutely ridiculous ways to solve a problem. They give us a box of crayons, but it’s not their fault we only have 12 crayons in the box.

The Unknowns of DLP

Well my friends, if you have listened to my 2k+ words in this limitless diatribe then you know we have tons of ways to tighten our DLP posture. We will always have unknowns like I mentioned earlier. Some of the challenges we have:

• You can’t stop someone from taking a screenshot
• You can’t force some of these stubborn vendors to implement managed app keys
• You can’t predict what Apple is going to do next
• You will adhere to their APIs

I’m sure there are tons more but by this point my head hurts. I have a motto that I tell people all the time, “It’s easier to do the right thing than the wrong thing.” I truly believe that if you do what is in the best interest of your company then you will likely be okay. We aren’t in the world of BlackBerry anymore. Much of what we do is best effort. I make no excuses, I own my flaws, and everyone else must be self-aware. A lack of self-awareness is everyone’s downfall. We should always trust but verify! I believe that if you visualize every workflow in your business you can limit the DLP risks.

I’m sorry that I hurt your brain

So nearly 3000 words later, I’m sorry that I have made you hate DLP now. I really believe everyone needs to own their platform. We can’t blame the vendors or anyone else. It’s our burden to bear and by being diligent you can build a platform that you are proud of. I implore all of you to never trust anyone. Be an engineer, tinker, test, visualize, and learn. We live in a word of misinformation and I believe in the words of Fox Mulder