U.S. patent application number 16/445446 was filed with the patent office on 2019-11-21 for data detection and protection policies for electronic file systems.
The applicant listed for this patent is Microsoft Technology Licensing, LLC. Invention is credited to Lynn AYRES, Jack KABAT, Raja Charu Vikram KAKUMANI, Anatoly KORETSKY, Mashuri LIBMAN, Joseph SCHULMAN, Andrey SHUR, Benjamin STULL.
Application Number | 20190354691 16/445446 |
Document ID | / |
Family ID | 48856980 |
Filed Date | 2019-11-21 |
![](/patent/app/20190354691/US20190354691A1-20191121-D00000.png)
![](/patent/app/20190354691/US20190354691A1-20191121-D00001.png)
![](/patent/app/20190354691/US20190354691A1-20191121-D00002.png)
![](/patent/app/20190354691/US20190354691A1-20191121-D00003.png)
![](/patent/app/20190354691/US20190354691A1-20191121-D00004.png)
![](/patent/app/20190354691/US20190354691A1-20191121-D00005.png)
United States Patent
Application |
20190354691 |
Kind Code |
A1 |
AYRES; Lynn ; et
al. |
November 21, 2019 |
DATA DETECTION AND PROTECTION POLICIES FOR ELECTRONIC FILE
SYSTEMS
Abstract
Systems and/or methods for deploying and implementing data loss
prevention (DLP) policy definition that may encapsulate the
requirements, control objectives and directives, and/or the
definitions of sensitive data types as stipulated directly or
indirectly by the regulatory policy are disclosed. In one
embodiment, DLP policies may be identified by an organization to
run on top of a set of electronic file systems (e.g., email
systems, file systems, web servers and the like). Organizations and
their administrators may implement a set of DLP policy instance
which are derived from DLP policy templates. DLP policy templates
may comprise both structure and meaning--and may acquire a given
DLP policy by the replacement of parameterized expressions with
desired parameter values. In another embodiment, the state of the
DLP policy instance may change according to the lifecycle of the
policy instance deployment.
Inventors: |
AYRES; Lynn; (Redmond,
WA) ; KABAT; Jack; (Sammamish, WA) ; KAKUMANI;
Raja Charu Vikram; (Bellevue, WA) ; LIBMAN;
Mashuri; (Woodinville, WA) ; STULL; Benjamin;
(Seattle, WA) ; KORETSKY; Anatoly; (San Antonio,
TX) ; SHUR; Andrey; (Redmond, WA) ; SCHULMAN;
Joseph; (Bellevue, WA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Microsoft Technology Licensing, LLC |
Redmond |
WA |
US |
|
|
Family ID: |
48856980 |
Appl. No.: |
16/445446 |
Filed: |
June 19, 2019 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
15064871 |
Mar 9, 2016 |
10372916 |
|
|
16445446 |
|
|
|
|
13545864 |
Jul 10, 2012 |
9317696 |
|
|
15064871 |
|
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04L 51/12 20130101;
H04L 51/063 20130101; G06F 21/60 20130101; H04L 51/34 20130101 |
International
Class: |
G06F 21/60 20060101
G06F021/60; H04L 12/58 20060101 H04L012/58 |
Claims
1-20. (canceled)
21. A method performed by a computing system, the method
comprising: identifying a DLP policy template configured to install
a data loss prevention (DLP) policy instance for an electronic file
system; creating a DLP policy template definition that defines a
property to be mapped to a deployment value at a time the DLP
policy template is used to create the DLP policy instance; creating
a main DLP policy object derivable from the DLP policy template
definition and configured to track shared metadata and state of the
DLP policy instance; creating a policy rule object defining a
policy directive as a match condition and an action derivable from
the main DLP policy object; and creating a data classification rule
object defining electronic data associated with the electronic file
system to which the policy rule object is applied.
22. The method of claim 21, wherein the electronic file system
comprising a file server configured to communicate with a client,
the client configured to request access to data and upload data to
the file server.
23. The method of claim 22, wherein the DLP policy instance is
implemented for a plurality of electronic file systems, each
electronic file system comprising one or more file servers, each
file server configured to communicate with a plurality of
clients.
24. The method of claim 23, wherein the DLP policy template
comprises a set of template component fields and is generic to the
plurality of electronic file systems, the method further
comprising: transforming the generic DLP policy template into a
first DLP policy instance that is specific to a first electronic
file system by parameterizing the set of template component fields
based on a first file system characteristic representing operation
of the first electronic file system; and transforming the generic
DLP policy template into a second DLP policy instance that is
specific to a second electronic file system by parameterizing the
set of template component fields based on a second file system
characteristic representing operation of the second electronic file
system.
25. The method of claim 24, wherein the first electronic file
system is configured to provide a first service that is different
than a second service provided by the second electronic file
system.
26. The method of claim 21, wherein creating a DLP policy template
comprises: creating a set of policy template operations, each
policy template operation configured to operate upon the DLP policy
template.
27. The method of claim 26, wherein each policy template operation
comprises at least one of: an install operation, a remove
operation, an import operation, an export operation, a query
operation, or a delete operation.
28. The method of claim 21, wherein creating a main DLP policy
object comprises: creating a set of main DLP policy object
operations, each DLP policy object operation configured to act upon
the DLP policy object.
29. The method of claim 28, wherein at least one of the main DLP
policy object operations comprises creating a new policy
object.
30. The method of claim 28, wherein each main DLP policy object
operation comprises at least one: creating a new state change,
editing a state change, or deleting a state change.
31. A computing system comprising: at least one processor; and
memory storing instructions executable by the at least one
processor, wherein the instructions, when executed, configure the
computing system to: identify a DLP policy template configured to
install a data loss prevention (DLP) policy instance for an
electronic file system; create a DLP policy template definition
that defines a property to be mapped to a deployment value at a
time the DLP policy template is used to create the DLP policy
instance; create a main DLP policy object derivable from the DLP
policy template definition and configured to track shared metadata
and state of the DLP policy instance; create a policy rule object
defining a policy directive as a match condition and an action
derivable from the main DLP policy object; and create a data
classification rule object defining electronic data associated with
the electronic file system to which the policy rule object is
applied.
32. The computing system of claim 31, wherein the electronic file
system comprising a file server configured to communicate with a
client, the client configured to request access to data and upload
data to the file server.
33. The computing system of claim 32, wherein the DLP policy
instance is implemented for a plurality of electronic file systems,
each electronic file system comprising one or more file servers,
each file server configured to communicate with a plurality of
clients.
34. The computing system of claim 33, wherein the DLP policy
template comprises a set of template component fields and is
generic to the plurality of electronic file systems, wherein the
instructions configure the computing system to: transform the
generic DLP policy template into a first DLP policy instance that
is specific to a first electronic file system by parameterizing the
set of template component fields based on a first file system
characteristic representing operation of the first electronic file
system; and transform the generic DLP policy template into a second
DLP policy instance that is specific to a second electronic file
system by parameterizing the set of template component fields based
on a second file system characteristic representing operation of
the second electronic file system.
35. The computing system of claim 34, wherein the first electronic
file system is configured to provide a first service that is
different than a second service provided by the second electronic
file system.
36. The computing system of claim 31, wherein creating a DLP policy
template comprises: creating a set of policy template operations,
each policy template operation configured to operate upon the DLP
policy template.
37. The computing system of claim 36, wherein each policy template
operation comprises at least one of: an install operation, a remove
operation, an import operation, an export operation, a query
operation, or a delete operation.
38. The computing system of claim 31, wherein creating a main DLP
policy object comprises: creating a set of main DLP policy object
operations, each DLP policy object operation configured to act upon
the DLP policy object.
39. The computing system of claim 38, wherein at least one of the
main DLP policy object operations comprises at least one of:
creating a new policy object, creating a new state change, editing
a state change, or deleting a state change.
40. A hardware computer-readable storage medium storing
computer-executable instructions that, when executed by a computer
processor, cause the computer processor to: identify a DLP policy
template configured to install a data loss prevention (DLP) policy
instance for an electronic file system; create a DLP policy
template definition that defines a property to be mapped to a
deployment value at a time the DLP policy template is used to
create the DLP policy instance; create a main DLP policy object
derivable from the DLP policy template definition and configured to
track shared metadata and state of the DLP policy instance; create
a policy rule object defining a policy directive as a match
condition and an action derivable from the main DLP policy object;
and create a data classification rule object defining electronic
data associated with the electronic file system to which the policy
rule object is applied.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] The present application is a continuation application of and
claims priority of U.S. patent application Ser. No. 15/064,871,
filed Mar. 9, 2016, which is a continuation of and claims priority
of U.S. patent application Ser. No. 13/545,864, filed Jul. 10,
2012, the contents of which are hereby incorporated by reference in
their entirety.
BACKGROUND
[0002] Modern organizations find it desirable to find, monitor, and
protect sensitive information (e.g., in electronic form)--such as
PII, Financial Data, Intellectual Property, and Health data in
e-mail. In order to do this, organizations attempt to model both
the data that should be protected--as well as the policies that
should be applied to the data. For e-mail, administrators attempt
to select different scoping mechanism for their policies such as
sender identity, recipient identity, and others.
[0003] In addition, administrators attempt to select and apply
actions such as audit, encrypt, require TLS transmission, etc.
Also, administrators try to take policies that are related to a
single objective such as regulatory objective and may try to manage
them as a single package, even though policies may contain
different rules, and enable/disable and test policy in a single
action.
SUMMARY
[0004] The following presents a simplified summary of the
innovation in order to provide a basic understanding of some
aspects described herein. This summary is not an extensive overview
of the claimed subject matter. It is intended to neither identify
key or critical elements of the claimed subject matter nor
delineate the scope of the subject innovation. Its sole purpose is
to present some concepts of the claimed subject matter in a
simplified form as a prelude to the more detailed description that
is presented later.
[0005] Systems and/or methods for deploying and implementing data
loss prevention (DLP) policy instances from a policy object model
are disclosed. In one embodiment, DLP policies may be identified by
an organization to run on top of a set of electronic file systems
(e.g., email systems, file systems, web servers and the like).
Organizations and their administrators may implement a set of DLP
policy instance by the parameterization of DLP policy templates.
DLP policy templates may comprise both structure and meaning--and
may be affected by the substitution of generic policy configuration
with deployment specific environment configurations at time of
policy creation by the replacement of parameterized expressions
with desired parameter values. In another embodiment, the state of
the DLP policy instance may change according to the lifecycle of
the policy instance deployment.
[0006] In one embodiment, a method for instantiating a DLP policy
from a set of policy templates is disclosed, the steps of the
method comprising: identifying an electronic file system upon which
a desired DLP policy is to be affected; identifying a set of DLP
policy templates suitable for the desired DLP policy;
parameterizing the DLP policy templates with desired DLP
Policy-specific data; and disseminating the parameterized DLP
policy instance to the electronic file system.
[0007] In another embodiment, a system for creating at least one
DLP policy instance for a set of electronic file systems is
disclosed, comprising: a set of DLP policy templates; each of the
DLP policy templates comprising a set of component fields; a DLP
policy template parameterization module, the template
parameterization module capable of replacing the component fields
with desired policy data; and a DLP main policy module capable of
creating a DLP policy instance for a set of electronic file systems
from the set of DLP policy templates.
[0008] Other features and aspects of the present system are
presented below in the Detailed Description when read in connection
with the drawings presented within this application.
BRIEF DESCRIPTION OF THE DRAWINGS
[0009] Exemplary embodiments are illustrated in referenced figures
of the drawings. It is intended that the embodiments and figures
disclosed herein are to be considered illustrative rather than
restrictive.
[0010] FIGS. 1, 1A, and 1B (collectively referred to as FIG. 1)
depicts one embodiment of a system that affects policy systems as
made in accordance with the principles of the present
application.
[0011] FIG. 2 depicts one embodiment of an implementation and
operation of a policy system in the context of e-mail as made in
accordance with the principles of the present application.
[0012] FIG. 3 depicts one embodiment of a system mail server
processing subsystem as it may interface with a policy system in
the context of e-mail.
[0013] FIG. 4 is one embodiment of one exemplary DLP policy
template, as it might be represented for a putative customer email
system.
DETAILED DESCRIPTION
[0014] As utilized herein, terms "component," "system,"
"interface," and the like are intended to refer to a
computer-related entity, either hardware, software (e.g., in
execution), and/or firmware. For example, a component can be a
process running on a processor, a processor, an object, an
executable, a program, and/or a computer. By way of illustration,
both an application running on a server and the server can be a
component. One or more components can reside within a process and a
component can be localized on one computer and/or distributed
between two or more computers.
[0015] The claimed subject matter is described with reference to
the drawings, wherein like reference numerals are used to refer to
like elements throughout. In the following description, for
purposes of explanation, numerous specific details are set forth in
order to provide a thorough understanding of the subject
innovation. It may be evident, however, that the claimed subject
matter may be practiced without these specific details. In other
instances, well-known structures and devices are shown in block
diagram form in order to facilitate describing the subject
innovation.
Introduction
[0016] Several embodiments of the present application disclose
systems, methods and mechanisms that allow policies to be created
for electronic file subsystems (for merely one example, e-mail) and
model them as a set of related objects that can be installed,
removed, state changed, and reported from at the same time in a
single operation. While the present embodiments are more drawn to
examples of e-mail systems, it should be appreciated that the
systems, methods and/or techniques described here are also
applicable to a wide variety of electronic file systems in a broad
sense--e.g., file systems, information protection and collaboration
(e.g. Microsoft Sharepoint.RTM. system), web servers, application
servers and the like.
[0017] As will be discussed in more detail herein, in many
embodiments, it would be desirable to employ a framework to model
complex industry regulations or company information governances as
a policy. Broadly, these policies--and their associated systems and
methods--are generally described in area of Data Loss Prevention
(DLP). Applications in this area may implement all or partial
components that address the policy processing as it applies to: (1)
managing the policy lifecycle; (2) enforcing and evaluating the
policy at policy enforcement points; (3) generating and viewing
reports and (4) managing violations for incidents
One Embodiment
[0018] FIG. 1 is a schematic diagram of a policy system as made in
accordance with the principles of the present application. As may
be seen in this embodiment, there may be several general policy
modules that may work with various electronic storage and/or
servers that may be set across a given organization. Broadly, there
may be a Policy Management System, multiple policy enforcement
points, and an Audit System for the setting and testing of a
policy, respectively.
[0019] As may be seen in FIG. 1, Policy Management System 100 may
comprise a policy authoring system 102, a policy store 104, a
policy dissemination system 106. As will be discussed in further
detail herein, these policy modules may be employed to set and
disseminate a policy for the organization. Policy may be affected
by various policy translation/mapping systems 108--which understand
the generic policy directives and transform them to the
contextually understood format by the policy enforcement points,
which may interface with various electronic data subsystems--e.g.,
Mail Delivery Systems 110, mail client systems like Microsoft
Outlook.RTM. system 112, information management systems like
Microsoft Sharepoint.RTM. system 114, File Systems 116, Web Servers
118 or other suitable electronic data subsystems that are capable
of policy enforcement and application.
[0020] Within these policy enforcement subsystems, there may be
modules therein that implement the policies effectively within the
subsystems. For example, such modules may be policy consumption,
local contextual processing--which may further comprise contextual
policy evaluation, contextual policy enforcement, and contextual
policy presentation.
[0021] As a part of these subsystems, it may be desirable to have a
contextual audit data generator. These audit data generators may be
in communication with an audit aggregation system 122 and an audit
presentation system 124.
[0022] It should be appreciated that many other architectures are
possible for implementing a policy system that may interface with
an organization's software suite--e.g., email, file servers, web
interfaces and the like. In addition, it may be possible (and maybe
desirable) for certain policy modules (for example, the policy
authoring and store, and audit functions) to be hosted apart from
the organization and supplied otherwise (e.g., server/client
relationship, cloud-based services or the like).
[0023] Once a policy system is implemented or otherwise configured
for an organization, such policy systems take on a runtime dynamic.
FIG. 2 depicts one embodiment of a runtime dynamic 200, as it might
apply to an exemplary email flow policy application. The
organization will typically have its email system and/or server 202
prior to the implementation of a policy system that will operated
on top of, or otherwise cooperatively, with the email system.
[0024] The policy system may consume policy content from multiple
sources. One such source may be as supplied with the system itself
in the form of out-of-box (OOB) set of policy templates that are
available as part of the product and may be acquired and installed
by a tenant system administrator and/or other suitable users 206.
Another source may be from Independent Software Vendors (ISVs) and
product partners, and consultants that provide custom policy
content for the consumption by the target organization. 204 may
supply the organization with custom DLP policies. In either case,
administrator 206 may perform particular configuration of a DLP
policy system--in this case, working with the organization's email
system. In addition to the installation/creation of the policy, it
may be desirable that ongoing policy maintenance and tuning may be
performed by in-house personnel or external contractors or
vendors--such as the tenant administrator or by the ISVs, partners,
and/or consultants. These may be represented by multiple operations
such as 206 and 204.
[0025] In operation, the policy directives may include operations
in contexts that the information workers interact with, such as
Outlook 210a or generic email client 210b, that may result in the
active education and/or notification of the policy to the
organization's users. The policy directives would determine what
content is considered sensitive and define the rules governing its
usage/handling within the organization. Both, what is the sensitive
content and rules governing its usage can be disseminated to the
end users as part of the policy directives. (e.g., email with
patient information, trade secret information or the like). The
policy directive may allow the user of sending this information
unrestricted, require explicit acknowledgement that the
communication contains sensitive information and the user takes
responsibility for its disclosure, or prevention of sharing
outright.
[0026] Once received, email server may process the email according
to the same policy definition for policy consideration, compliance
and/or processing directly (or the policy system may be operating
apart from the email server in a server/client relationship or the
like). Once the email is scanned for sensitive content, additional
actions may take place such as holding the email prior to sending
outside the email server, the organization or the like. Any
non-compliance with policy (or period reports of generally
compliant email traffic) may be sent to an auditor 212 for follow
up. Such follow-up may be to retrain affected employees--or it may
detect some error in the dynamic flow and/or operation of the
policy system. Any policy processing errors may be referred back to
either the system administrator or to the ISV for correction. The
mail processing server will enforce that the policy was uniformly
applied no matter what client was used as part of the authoring
experience. If the policy requires sender acknowledgements, these
may be enforced for presence or the mail will be rejected back to
the sender.
[0027] FIG. 3 is the e-mail server processing details of the policy
application--e.g. exchange server (box 202 in FIG. 2). FIG. 3
depicts one possible embodiment of a system mail processing
subsystem 300 as it may interface with a policy system. The e-mail
server's policy processing may be performed by an agent that is
activated at various stages of mail processing. One such agent
could be the exchange transport rules agent 302 which may employ
processing of content analysis predicate 302a in conjunction with
schema for content analysis predicated 318. Transport rules may be
stored in 316 and administrators/user may edit content analysis
predicates with module 314b via a UI 314.
[0028] The agent may interface with a message content and
attachment text extraction module (referred to herein as "FIPS")
306 and content analysis module to scan for sensitive content. FIPS
may be affected as a component that does the content extraction and
conversion to text (e.g., both mail messages and attachments) and
may pass the extracted content into the classification engine for
analysis of any sensitive content as defined by the policy
directives. FIPS may comprise a text extraction engine 306b and
communication modules with text extraction engine and the content
analysis engine, 306a and 306c respectively. FIPS may be the same
as the DLP policy evaluation module--e.g., it may be constructed as
a sub-component making up DLP policy evaluation--i.e., the one that
does text extraction which is then fed into the classification
engine for analysis for any sensitive information as defined by the
DLP policy.
[0029] The text extraction module may interface (perhaps via a
communication protocol 308) with the content analysis/scanning
engine/module 310 which may perform the text analysis on the text
identified with the e-mail bodies and any attachments. The text
analysis engine may identify sensitive content based on the policy
information which has been stored in the content rules store 312
such as AD. Such rules may be edited by administrators/users via
module 314a via UI 314.
Data Detection and Prevention Policy Object Model Embodiment
[0030] The present systems, methods and/or mechanisms may be
implemented by an object model approach. In one such embodiment,
the complexities of a regulatory policy may be represented through
a policy template concept which encapsulates the policy directives
and controls and offers methods for its lifecycle management. It
may be desirable to have the following objects defined and/or
associated with an object model that may allow for ease of
implementation: (1) policy template objects that allow for the
installation of the policy and all associated objects; (2) a main
policy object that tracks shared metadata and state; (3) a set of
policy rule objects, mapping to the policy object, which define the
policy directives as match conditions and actions for each policy
and (4) data classification rule objects which define the structure
of the sensitive data that the policy, and the regulatory
specification, specify as sensitive data definitions.
[0031] For these various objects, it may be desirable to define and
implement operations that act upon these objects. For example, for
an exemplary policy template object operations might comprise: (1)
install, (2) instantiate, and (3) remove. Operations for a main
policy object might comprise: (1) creating new policy object from
template; (2) creating new, editing, deleting, and managing state
changes through its lifecycle. As may be the case, each of these
operations may have impact on multiple objects associated with the
policy which themselves implement the policy directives as
appropriate in any of the applicable policy enforcement points. In
the case of a policy system for email, there may be a runtime
behavior for email--that may be subject to the policy--across a
number of policy enforcement points which may include: (1) e-mail
client (2) e-mail server (3) e-mail storage system (4) e-mail
processing gateways etc. Each of the policy enforcement points
interprets and applies the policy in accordance with the state of
the policy as it relates to the policy deployment lifecycle which
may include (1) audit only evaluation of the policy (2) audit and
notification evaluation of the policy and (3) full enforcement of
the policy directives.
DLP Policy Template Embodiment
[0032] In one embodiment, a DLP policy template is a component
description that identifies the characteristics of the policy and
how it is realized using components--i.e., a configuration for
components. It may be non-environment specific--e.g., a stencil
used to create a deployment specific version. In addition, it may
not have any state since it is just a definition. In addition, it
may offer a very simple set of operations--such as: Import, Export,
Deletion and Query. In one possible embodiment, the template may be
authored using an XML document that may be used to express the full
construct of a regulatory policy in an implementation independent
format, as depicted in FIG. 4.
[0033] In this embodiment, the Import operation may allow for the
import of the definition. The Import operation may be provided for
"out of the box" (OOB) policy definitions that are built into the
system. In addition, Import may be used to provide updates version
of the policy templates for an OOB policy templates. Further, the
import may be used to incorporate into the system additional policy
definitions that are provided to meet custom regulatory objectives
or organizational needs. These additional policy definitions may
extend built-in policy definitions or create brand-new policy
definitions.
[0034] The Export operation may allow for the saving, backup and
offline updates of the policy definitions. Export may provide
access to the serialized version of the template and may be used to
migrate the template from one environment to another.
[0035] Deletion operation removes the policy definition from a
deployment environment. In one embodiment, it may not be desired
that Deletion is supported for OOB definitions. Query operation may
allow for the discovery of the definitions for both OOB policies
and any additional policies that have been added into the
system.
An Exemplary DLP Policy Template Parameterization
[0036] For merely one example, FIG. 4 depicts one putative set of
DLP Policy Template components 400 that might be implemented to
realize exemplary customer email flow compliance, possibly based on
specific regulations. As may be seen, the DLP Policy comprises a
set of components (having an associated structure 402 and meaning
404)--e.g., Publisher (406, 408), Version (410, 412), Policy Name
(414, 416), Description (418, 420), Meta-Data (422, 424), Set of
Policy Constructs (426, 428) and a set of Data Classification
Packages (430, 432). It will be noted that a set of meanings may be
associated with these components. In this example, the interface
for managing the DLP policy templates objects may be PowerShell or
any suitable web interface.
[0037] In one embodiment, it may be desirable that the template
definition allow defining properties that may be mapped to
deployment values at time the template is used to create a DLP
policy instance. For example, two main properties may be defined
that utilize this capability: (1) exception Distribution List (DL)
which may be mapped to a default DL provisioned within a DLP
deployment and (2) a DLP reporting mailbox that will be used as the
destination for notifications of any policy violation
detections.
DLP Policy Template Parameterization
[0038] In one embodiment, a simple property replacement mechanism
may be used to accomplish parameterization of fields in a template.
The following may be desired for the replacement mechanism: (1) the
ability to specify parameterized expression for DLP policy
construct elements in a DLP template; (2) the ability to pass
parameter values as part of DLP template instantiation; (3) the
ability to use parameterized expressions in both OOB DLP policy
templates and ISV created ones; (4) the support for Unicode strings
in the DLP policy template definition and as substitution character
input; (4) the ability for API to discover which properties are
parameterized in a template; (5) the ability to strong type the
parameterized properties in a template.
[0039] This mechanism may be implemented by a simple find and
replace of name value pairs in a template. The template's DLP
policy constructs would allow the specification of substation keys
for which replacement values may be provided. For example, the
substation keys may be of the form: %%keyName%%, where keyName is
an identifier. The interface may allow the passing of a name value
pair that will provide a mapping for each keyName to a value.
[0040] For merely one example, the following excerpt may be given
from a policy definition in the PCI-DSS DLP policy template, as
shown in FIG. 4:
TABLE-US-00001 <?xml version="1.0" encoding="utf-8"
standalone="yes" ?> <dlpPolicyTemplates>
<dlpPolicyTemplate version="15.0.3.0" state="Enabled"
mode="Audit"> <contentVersion>1</contentVersion>
<publisherName>Microsoft (Beta)</publisherName>
<name> <localizedString
lang="en-us">PII</localizedString> <localizedString
lang="fr-fr">PII</localizedString> </name>
<description> <localizedString lang="en-us">Detects the
presence of information considered to be PII in the U.S. This
includes the presence of data like SSN and Driver's License in
email. After completing your testing, configure the rules in this
program such that the transmission of information complies with
your organization's policies. Examples include configuring TLS with
known business partners, or adding more restrictive transport rule
actions such as rights protection.</localizedString>
<localizedString lang="fr-fr">Detecte la presence de
l'information consideree comme PII aux Etats-Unis. Cela comprend la
presence de donnees SSN et permis de conduire dans le courriel.
Apres avoir complete votre test, configurez les regles dans cc
programme tel que la transmission de l'information conforme aux
politiques de votre organisation. Configuration de TLS avec les
partenaires commerciaux connus, ou ajouter des actions de regle de
transport plus restrictives telles que la protection des droits des
exemples.</localizedString> </description>
<keywords> <keyword>KeyWord1</keyword>
<keyword> KeyWord2</keyword> </keywords>
<ruleParameters> <ruleParameter type="string"
required="True" token="%%ReportSeverity-1%%">
<description> <localizedString lang="en-us">Parameter
Description - reportseveritylevel#1</localizedString>
<localizedString lang="pl">parametr opis -
reportseveritylevel#1</localizedString> </description>
</ruleParameter> <ruleParameter type="string"
required="False" token="%%ReportSeverity-2%%">
<description> <localizedString lang="en-us">Parameter
Description - reportseveritylevel #2</localizedString>
<localizedString lang="pl">parametr opis -
reportseveritylevel#2</localizedString> </description>
</ruleParameter> </ruleParameters>
<policyCommands> <commandBlock>
<![CDATA[New-TransportRule -name "PII-outside" -comment
"Monitors for PII content sent to outside the organization"
-DlpPolicy "%%DlpPolicyName%%" -SentToScope NotInOrganization -
MessageContainsDataClassifications @{Name="US Social Security
Number (SSN)"},@{Name="Passport Number (U.S/U.K)"}
-ReportSeverityLevel %%ReportSeverity-1%%]]>
</commandBlock> <commandBlock>
<![CDATA[New-TransportRule -name "PII-within" -comment "Monitors
for PII content sent inside the organization" -DlpPolicy
"%%DlpPolicyName%%" - SentToScope InOrganization
-MessageContainsDataClassifications @{Name="US Individual Taxpayer
Identification Number (US ITIN)"},@{Name="US Social Security Number
(SSN)"},@{Name="Passport Number (U.S/U.K)"} - ReportSeverityLevel
%%ReportSeverity-2%%]]> </commandBlock>
</policyCommands> </dlpPolicyTemplate>
</dlpPolicyTemplates>
[0041] The example above may be affected by the substation of two
keywords: "%%ReportSeverity-1%%" and "%%ReportSeverity-2%1%" (as
given above) as part of the DLP policy creation from this template
using the following sample syntax:
[0042] [PS] C:\>new-DLPPolicy -Template PII -State Audit
-Parameters @ {"ReportSeverity-1"="High";
"ReportSeverity-2"="Low"}
[0043] This would result in the creation of the resulting policy
directives, possibly implemented through Exchange Transport Rules
(ETR), with the parameterized keys substituted with the specified
values from the "Parameters" argument. It should be appreciated
that this mechanism would be available for both DLP OOB
templates--as well as custom templates from ISVs and others. If any
parameterized properties do not have corresponding value passed in
through the Parameter option, it may be desirable that an error is
generated.
DLP Policy Template Properties
[0044] The following table gives some examples of DLP Policy
Template object and their associated properties. It will be
appreciated that other template components may be similarly set
out.
TABLE-US-00002 NAME BASE TYPE RESTRICTIONS DESCRIPTIONS Identity
String Guid ID of the object. Unique and immutable. Can be
specified at create time. Name String <64 Unicode A user
friendly name to describe the chars object. Recommended to be
unique but not enforced by the system. "Name" is an alternative
mechanism used to identify the object and expected to be used by
admins in PowerShell interface. Changeable by user. PublisherName
String <64 Unicode Who published this DLP template. chars
Description String Unicode chars Description of the policy
template. Regulation String collection <64 Unicode List of
regulations targeted by this chars per item DLP profile template.
Region String collection 2 chars per item List of countries
targeted by this DLP profile template. The values are based on the
two-letter country codes as assigned part of the ISO 3166-1 Part 1
specification which is commonly used in Microsoft Windows .RTM.
software to specify region designation of localization components.
Keywords String collection <64 Unicode Additional keywords
applicable to chars per item the policy used for searches during
discovery.
[0045] DLP Policy Template Operations
[0046] The following table gives some examples of DLP Policy
Template operations and their associated descriptions. It will be
appreciated that other template operations may be similarly set
out.
TABLE-US-00003 VERBS DESCRIPTION Get Standard query task. Returns
all DLP policy templates in the deployment environment. Support -
Filter parameter to specify server side filtering options.
Filtering may be based on the following properties: PublisherName,
Regulation, Region, Keywords, etc. Import Imports a policy template
from a serialized version into a deployment environment. Export
Inverse of Import. Exports a serialized version of the DLP policy
template. Remove Removes a DLP policy template definition.
DLP Policy Instance
[0047] DLP policy instance is the result of creating a DLP policy
object from a template in a deployment environment. It represents
the set of instantiated component objects employed to implement the
policy definition in the template (e.g. ETRs, data classification
rules etc.). An instance is deployment-specific--i.e., it tends to
contain definitions that reference components and elements that are
specific to a customer environment and hence it tends to be
non-portable across deployments.
[0048] Unlike a template, a DLP policy instance has state which
represents the lifecycle state within the customer's deployment
(for example, audit or enabled). The DLP policy state may be used
to control the state of the components that comprise the policy.
Changes in the DLP policy instance state apply corresponding
changes within the policy objects controlled by the DLP policy.
Three basic states exist for a policy which represents a customer's
progression in realizing their policy implementation. The following
table gives one embodiment of a state table of a DLP policy
instance:
TABLE-US-00004 STATE DESCRIPTION Audit Customer is collecting data
on what kind of content is being sent through his mail flows
without modifying any behavior. This may be used to adjust/tune
policies or to determine impact and/or actions that would result
from enabling the policy. Notify Client is moving to start to
educate the users on the DLP policies in place and get them
familiar with the business processes around sensitive content. It
may desired to selectively enable enforcement actions, or
alternatively, not to enable enforcement actions at all.
Enforcement All aspects of the policy are enabled.
[0049] In one embodiment, it may be desirable that there are no
restrictions in terms of the movements between the states. A
customer may choose to skip any of the policy or move from any one
state to another. In addition to controlling the policy deployment
states, the policy may also be disabled--which results in the
policy being ignored in the policy enforcement points.
[0050] While the DLP policy is used to control the state of the
sub-components, it is possible for the sub-components representing
the individual policy directives (e.g., ETRs) to have a different
state than the DLP-policy. This may allow the user to change the
individual policy directive of the policy to be in a different
state--for example, when adding a new directive to the policy or
when troubleshooting a directive of the policy. Each policy
directive may also maintain a corresponding representation of its
state which maps to the values of the DLP policy state. These
states may also be controlled independently at the directive level.
For example, the audit state for a directive may be turned-off; by
setting the directive in a disabled state. Similarly, Notify state
may be turned off for a specific directive.
DLP Policy Properties
[0051] In one embodiment, the DLP policy may follow common set of
properties exposed across other components that comprise the
application area--e.g., Microsoft Exchange.RTM. system--and may
include the following properties:
TABLE-US-00005 BASE RESTRIC- NAME TYPE TIONS DESCRIPTIONS Identity
String Guid ID of the object. Unique and immutable. Can be
specified at create time. Name String <64 Unicode A user
friendly name to chars describe the object. Recommended to be
unique but may not be enforced by the system. Name may be an
alternative mechanism used to identify the object and expected to
be used by admins in PowerShell interface. May be changeable by the
user. Description String Unicode Description of the policy chars
template. State Enum Indicates the desired state of the DLP policy
and its sub- components. While the DLP policy is used to control
the state of the sub-components, it is possible for the sub-
components to have a different state than the DLP policy.
[0052] DLP Policy Object Operations
[0053] In one embodiment, the main DLP policy object may follow
common set of operations exposed across other components that
comprise the application area--e.g., Microsoft Exchange.RTM.
system--and may include the following operations:
TABLE-US-00006 VERBS DESCRIPTION New Creates a new DLP policy from
a template definition. The template may be an OOB template; or the
contents of a template obtained from an ISV or other third party.
If no template definition or content is specified, an empty DLP
policy may be created with no policy elements. Get May be a
standard query task. Returns all or a subset of DLP policies in a
tenant's space. DLP policy instances may be scoped to within a
tenant scope since they represent the tenant's implementation of
the policy components. Set The Set operation may be used to modify
parameters of the policy. May be used in the change of a DLP
policy's state which may also change the state of other policy
components that support state semantics. Remove The Remove
operation may delete the DLP policy and its associated components
from the system. The user may be requested to confirm if policy and
data classification objects should be removed from the system.
Import- The Import-DLPPolicyCollection may allow the serialization
DLPPolicyCollection of the policy components for backup/transport
and maintenance. The Import-DLPPolicyCollection may re- create the
policy components from a previously serialized version. Export- The
Export-DLPPolicyCollection may allow the serialization
DLPPolicyCollection of the policy components for backup/transport
and maintenance.
[0054] In one embodiment, a single DLP policy instance may have 0
to N policy directives that implement its behavior. This may be
delivered through, e.g., Microsoft Exchange.RTM. transport rules. A
transport rule may be part of 0 or 1 DLP policy instances. A single
policy directive may allow the definition across any number of
policy enforcement points, for example for both server side mail
flow processing directives and the e-mail client processing
directives.
[0055] In addition, a single DLP policy instance may have 0 to N
data classification objects bound to it. The data classification
specification defines what is considered sensitive content within
the scope of the policy and how this content should be identified
with the e-mail content. The interface for managing the DLP policy
instance objects may be PowerShell, web interface or others. The
DLP Policy may comprise the same or similar Verbs as disclosed for
the DLP Policy Operations, as given above.
[0056] What has been described above includes examples of the
subject innovation. It is, of course, not possible to describe
every conceivable combination of components or methodologies for
purposes of describing the claimed subject matter, but one of
ordinary skill in the art may recognize that many further
combinations and permutations of the subject innovation are
possible. Accordingly, the claimed subject matter is intended to
embrace all such alterations, modifications, and variations that
fall within the spirit and scope of the appended claims.
[0057] In particular and in regard to the various functions
performed by the above described components, devices, circuits,
systems and the like, the terms (including a reference to a
"means") used to describe such components are intended to
correspond, unless otherwise indicated, to any component which
performs the specified function of the described component (e.g., a
functional equivalent), even though not structurally equivalent to
the disclosed structure, which performs the function in the herein
illustrated exemplary aspects of the claimed subject matter. In
this regard, it will also be recognized that the innovation
includes a system as well as a computer-readable medium having
computer-executable instructions for performing the acts and/or
events of the various methods of the claimed subject matter.
[0058] In addition, while a particular feature of the subject
innovation may have been disclosed with respect to only one of
several implementations, such feature may be combined with one or
more other features of the other implementations as may be desired
and advantageous for any given or particular application.
Furthermore, to the extent that the terms "includes," and
"including" and variants thereof are used in either the detailed
description or the claims, these terms are intended to be inclusive
in a manner similar to the term "comprising."
* * * * *