Coming up on the show, we share our top five tips
for successfully accelerating information protection
inside of your organization.
And we show you key technology updates
for Azure information protection,
such as scope policies for scaling up
and personalizing the default information classification labels
for specialized teams.
And, preparing for the next generation
over rights management protected secure email.
Microsoft Mechanics
I'm joined once more by Dan Plastina,
a resident expert in information protection.
Dan, welcome to the show.
Hi Simon, good to be back.
So, information protection and governance is a topic we've covered quite a lot on Microsoft Mechanics.
I know that it's a lot easier said than done.
For those folks out there who may be a little bit less
familiar with Azure information protection, though.
Can you share a little bit about what your team has been doing to ease the burden?
Absolutely.
Our whole focus with Information Protection
really in providing an answer to the data loss challenge, is simplicity.
We're making protecting information a whole lot easier.
Data Lifecycle is anchored
in classification and labeling.
And that will be our focus today.
The goal really is to make it trivial for a user to classify information with a single click.
The goal then is to make sure that we're not impacting their productivity.
Labeling and protection are then taken care of indirectly
as part of that classification phase.
So beyond making the task simple.
People are obviously central to this successful adoption of information protection.
Let's move on and start with your first tip.
Well the success of an information protection deployment
Starts with having the right set of initial labels.
So our first tip is thus to pick standardized and approachable labels.
That's a really interesting choice of words.
I get that approachable probably means that
we really need the users to be able understand those labels,
so that they can take the lead on assessing the sensitivity of the information
that they create, consume and share
since they're probably the best place to do so.
But, what do you mean by standardized?
It's a lot harder to pick good names than one would assume.
I spent the last year of my life helping people pick terms
or convincing them to change what they already have picked.
Users are just not data geeks.
Terms like medium business impact or level C3.
They don't do much to win over a normal user population.
Unless they are part of a secret agency or something.
What we want to do is to come up with common language that has the user connect
with the terms and get a sense of that sensitivity progression.
We want them to succeed with well-tested words.
Words that they can easily relate to.
That makes sense, but the space is really nuanced.
I presume we got a set of tried and tested labels,
that are maybe automatically configured in labels?
Yeah, we sure do and we recommend five labels be used.
These have held up to usability test we've done and reviews with a lot of customers.
What we're doing right now is picking those defaults
that we will set for all new customers.
What me to show them to you?
Yeah that would be great.
Let's just take a peek at a normal document.
So here what I have is a word doc.
When you create new word documents
They'll default to general.
I'll explain that a bit more later.
Then you have a choice of labels if you want to change it.
If I hover over "Personal", it will tell you it's non-business data for personal use only.
Public.
This is content that's been vetted or approved for public consumption.
LIke a brochure for a team.
General.
This is the perfect example of how tricky this could be.
General is really business internal.
But, internal creates ambiguity in modern organizations
because a lot of folks are now outsourced.
So for example, if a company were to outsource legal.
Is sharing to your lawyer's internal or not?
And so that's where the term "General" comes in.
So this is a great new term that we use.
"Confidential" is a term that really is well understood and used internationally.
So there's no problem there.
And that's where we start applying protection.
Highly confidential.
Re-uses of the term confidential for a reason.
It's very clear that it's more confidential then confidential.
In some parts of the world
and some organizations have used the term restricted.
Confidential, Restricted.
Restricted, Confidential.
It's not quite clear.
We see that in Europe, often people flip that around.
So using Highly Confidential as the more sensitive one
And Confidential as the least.
You don't have that problem with the ordering.
Ok, It's nuance but it seems simple enough when you describe it like that.
Do all of these labels apply to everyone
in every single Department in every job role?
Yes.
Everyone should have this common set of global labels.
No exceptions.
You want to train people once on one set and that's it.
With this done, you're then able to teach your IT system
to look for the labels universally
across all of your trust sensor fabric.
So for example, I'll show you
And Mcas admin console.
and here you can see that
Complication Label input = Confidential.
Here we filtered content
using Mcas which is Microsoft Cloud App Security.
It blocked certain data
of confidential or above from going to the Cloud.
And so that's an example of that.
So that was Cloud app security.
I think we're also working with other DLP vendors, right?
Yes, we're working with all the large DLP vendors in this space.
Now if you're in a large organization through,
I would imagine that some users may want to narrow down the sharing of more restrictive types of data.
Absolutely.
For those users we've created a secondary concept we call "Sub -labels".
This is really tip number two.
It is to create Sub Labels for key departments.
The idea here is the ability to narrow down
who can access data
lets you implement the often required ethical walls
that naturally exists in larger or regulated organizations.
Let's take a look at what we've set up here for our company
and you'll get a good sense for that.
So here I have a document
that is quite a bit more sensitive than the blank one I showed earlier.
And general is not appropriate as the default here.
So if I click on "Confidential"
you'll see another list of options here.
We'll talk about how these get configured later.
But you'll see here that I've got
one for legal, one for finance, and the same thing here exists on the "Highly Confidential" side.
Including one called "Project Samos".
Again, i'll touch on that in a minute.
So I can just click "Confidential Finance"
and the active protecting this document will make this document
sensitive and scoped only to the finance team.
This is going to vary by organization size
and the data that's most important and most sensitive to your business.
Absolutely.
Typically, the larger the organization the more sub-labels you require.
You do not need to change the global labels.
In fact, you don't want to change them.
This is your "Hey, my team is special" pressure valve.
So you can acknowledge the teams are special.
Let's start with the least possible number of these.
Generally you want to work with each of the business divisions
and get a sense for what their data protection requirements are
and their ambitions.
Those may differ.
Together, you'll come up with a model
where you're going to try to keep things as similar as possible for all these groups.
But you find some conflicting needs.
I can give you too common examples we see quite a bit.
For finance employees,
generally the default classification may need to be confidential.
Because day-to-day they deal with a lot of sensitive stuff.
Now just because financial people, legal, or HR deal with sensitive stuff,
that doesn't mean you want to do that for everybody in your company.
So that's an exception.
Another great example is Attempted Project.
These are projects where sometimes only some people should know of the project,
let alone access the data.
This is common in merger and acquisition work.
Legal teams have a lot of issues as well.
For example, when I purchased the secure islands company last year,
we code named it "Project Samos".
And I would have created a label
just for "Project Samos" like the one I just showed you.
Now only I should see that.
And you don't really want to let other people see it
because the curiosity would cause people to talk,
and people talking would cause data to leak.
So really, this brings us to Tip 3.
Being able to use scope policies
to control these specialized behaviors.
You've recently released scope policies.
Can we dive into those for a little bit?
Yeah, absolutely.
Let's go take a peek at the admin console.
So here in the admin console, you'll see one important shift from last time.
The first screen we see here
has now Scoped Policy sets.
You'll see global,
which is the default policy for all users.
And I've created two new ones to showcase what we've done today.
You can click on this little "Add New Policy Button" here.
To create new ones
we're just going to stick with what I've done for the demo.
So, looking at global
you can see the core labels that are visible to users.
Personal, Public, General, Confidential, and Highly confidential.
And you also see some of the items that showed up when we were in word.
So this is part of the global set
available to everybody.
And it requires a default which is on, and its general.
I also require justification here.
So if someone lowers the policy, they have to justify doing so.
That makes sense.
Now, let's go take a look at Projects Samos.
The Project Samos policy is similar
this is where here you can see the Project's Samos is a new sub-label.
You can see it here it says "Project Samos" in the policy column.
And if you want to add new ones like these
you would just click here and "Add sub-label".
So you can add new ones.
This particular one you can see, select which users groups get this policy.
Project Samos user is a security group.
I'm a member of it and I see that label.
If you're not a member of it, you would not see that label.
Now let's go look at the management one.
Same thing.
The management one is for managers.
So anyone who's a manager in this group sees these labels.
And hear what I've done is under "Confidential",
and "Highly Confidential" I've created Human Resources, Legal, and Finance.
I have the ability to also mandate behavior.
So on a default labeling, general is this.
If I want to change it for the managers,
I could say "Confidential full-time employees".
And if I push this out everybody who's in a manager group,
would get a different default than the global template of general.
So the idea here is that everyone get's global
unless there's a specific override for that.
Yes precisely.
So, what I like about Tip 3 is the scope policies mean that
we still consistently label things.
Users just see the labels that they need.
IT can customize the actions that correlate to the label.
Yeah, that is exactly right.
You know early on I said we had made it a lot easier.
These tips will really make deployment of this a lot easier in your company.
This is great but, how does IT get to the point where all of their data has been classified?
Surely we can't expect users to just go along classifying everything.
Yes this is in fact Tip #4
where I suggest you strongly focused on encouraging the right behavior.
Let's review the four approaches to getting data classified.
Automatic, Recommended, Reclassification, and User set.
Automatic is all about doing something via rules.
If you go too far and have a reliance on automatic,
you're not going to achieve nirvana there.
They don't put too many eggs in that basket.
On the other extreme,
you've got User set policy.
This is where you expect your users to classify everything manually.
Again, don't hold your breath for that turning out perfectly.
Really where there's magic is in the middle.
The combination of recommended and reclassification
really can do wonders.
So this is where you pick a default.
Or a couple of defaults if you're using the Scope Policies capability.
And from there, let the user change or reclassify things.
Add a little bit of automation
in the form of recommendation.
And now you hit the sweet spot.
So let me show you how a recommendation works.
I'm back in the document we used earlier
and I had classified manually.
We've set up some triggers on the server side
and if I type in "Confidential Legal",
when I go to save this document a recommendation came up
and it says "Confidential Legal".
I have the right to change now.
I can type in something else or pick something else.
If I change this to say "Confidential HR", you'll see the recommendation change to HR.
So here the user was offered a choice.
And I can accept it or override it.
Dan, what else can IT do to encourages users to have the right behavior?
Thus far, we focused a lot on getting classification right.
You can be up and running in a fraction of the time with these tips.
Deployments are really easy to control.
You set up your global policy,
and then you deploy the add-ins to the end points you want to manage.
So you can get going with that.
With that said, let's change gears here and focus on securing email
with the other half of the problem.
Tip 5 is about safeguarding email communications.
Office 365 users
will simply send email the way they do today.
The users with Outlook will continue to have a great native experience
And those using any other identity or any other mail client
will now get a great experience as well.
And so, this is so much easier to show.
So why don't I just walk you through what it looks like?
So here I'm in Outlook.
I have a protected message right next to an unprotected message.
And going between them is really straight forward.
This one here says "Do not forward".
This will carry through to the others.
Here, I'm in outlook.com
and I'm looking at the same "Do not forward." email message
also encrypted, seamless.
I was able to just log into Outlook and read these messages.
Let's take a peek at a different client.
Now in this case, i'm in a google mail client
in a chrome browser.
And I have that same protected email message.
But let me show you what it looks like today, first.
This is a message that's encrypted where we tell you to buy Office to read it.
Not a great customer experience, and this is why email gateways exists today.
Moving forward,
reading that sensitive email message is just a matter of saying "Click here to read".
What we do is invite you to prove who you are before we decrypt it.
Now, sign in with Google would just do single sign-on
exactly the same way the live ID demo looked.
Let's try the single use code.
So here what I've done is I've been invited
to go to my inbox to prove that I am that person.
so I'll go back to my inbox,
see that a passcode has arrived.
i'm going to copy this passcode.
And I will paste it in here.
When I hit continue,
the customer who sent me this data
they're setting up a mail environment
that let's me read the encrypted message.
Now I can read it, reply, interact with you.
You don't know that I'm using this read online experience.
And I don't really care what clients you have.
So this just makes everything work.
And it doesn't interrupt the regular mail flow that anybody is actually use to using.
Right, that was the core design goal.
Again, we'll be rolling this out in the coming months.
So you want to get ready for it.
The way you want to think about this is, if you have an existing solution.
Figure out how you're going to unwind that.
If you don't have anything,
figure out how it is you're going to get a rapid deployment with select teams in your company.
This will be a game changer in terms of sending secure email
That was great, Thanks Dan.
And, very useful explanation.
Hopefully these top five tips that we've gone through
are going to help you really kickstart information protection inside your organization.
How can folks learn more?
If you want to learn more tips on information protection,
we encourage you to follow our blog series at the link below.
You can also contact our alias to specific answers to your questions.
Thanks Dan.
And thank you for watching Microsoft Mechanics.
Don't forget to keep tuning in, for the latest in tech updates.
We'll see you next time.
Microsoft Mechanics