Symantec™ Data Loss Prevention Incident Reporting And Update API Developers Guide Symantec DLP 15.5

User Manual:

Open the PDF directly: View PDF PDF.
Page Count: 108 [warning: Documents this large are best viewed by clicking the View PDF Link!]

Symantec™Data Loss
Prevention Incident
Reporting and Update API
Developers Guide
Version 15.5
Symantec Data Loss Prevention Incident Reporting
and Update API Developers Guide
Documentation version: 15.5a
Legal Notice
Copyright © 2018 Symantec Corporation. All rights reserved.
Symantec, CloudSOC, Blue Coat, the Symantec Logo, the Checkmark Logo, the Blue Coat logo, and the
Shield Logo are trademarks or registered trademarks of Symantec Corporation or its affiliates in the U.S.
and other countries. Other names may be trademarks of their respective owners.
This Symantec product may contain third party software for which Symantec is required to provide attribution
to the third party (“Third Party Programs”). Some of the Third Party Programs are available under open
source or free software licenses. The License Agreement accompanying the Software does not alter any
rights or obligations you may have under those open source or free software licenses. Please see the
Third Party Legal Notice Appendix to this Documentation or TPIP ReadMe File accompanying this Symantec
product for more information on the Third Party Programs.
The product described in this document is distributed under licenses restricting its use, copying, distribution,
and decompilation/reverse engineering. No part of this document may be reproduced in any form by any
means without prior written authorization of Symantec Corporation and its licensors, if any.
THE DOCUMENTATION IS PROVIDED "AS IS" AND ALL EXPRESS OR IMPLIED CONDITIONS,
REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE
DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY
INVALID. SYMANTEC CORPORATION SHALL NOT BE LIABLE FOR INCIDENTAL OR CONSEQUENTIAL
DAMAGES IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF THIS
DOCUMENTATION. THE INFORMATION CONTAINED IN THIS DOCUMENTATION IS SUBJECT TO
CHANGE WITHOUT NOTICE.
The Licensed Software and Documentation are deemed to be commercial computer software as defined
in FAR 12.212 and subject to restricted rights as defined in FAR Section 52.227-19 "Commercial Computer
Software - Restricted Rights" and DFARS 227.7202, et seq. "Commercial Computer Software and
Commercial Computer Software Documentation," as applicable, and any successor regulations, whether
delivered by Symantec as on premises or hosted services. Any use, modification, reproduction release,
performance, display or disclosure of the Licensed Software and Documentation by the U.S. Government
shall be solely in accordance with the terms of this Agreement.
Symantec Corporation
350 Ellis Street
Mountain View, CA 94043
http://www.symantec.com
Chapter 1 Introducing the Symantec Data Loss Prevention
Incident Reporting and Update API ............................ 7
About updates to this guide .............................................................. 7
About the Incident Reporting and Update API ...................................... 7
About Incident Data Views ......................................................... 8
Features of the Incident Reporting and Update API ......................... 9
Components of the Incident Reporting and Update API ................... 9
Requirements for using the Incident Reporting and Update
API ............................................................................... 10
About localization of system-defined fields .................................. 11
About Incident Reporting and Update API security .............................. 11
Chapter 2 Implementing an Incident Reporting and Update
API client ......................................................................... 12
About Incident Reporting and Update API client implementations ........... 12
About reporting clients ............................................................ 13
About update clients ............................................................... 14
Implementing an Incident Reporting and Update API client ................... 14
Installing a development system ...................................................... 15
Creating a user and role for an Incident Reporting and Update API
client .................................................................................... 16
Creating a saved report for an Incident Reporting and Update API
client .................................................................................... 19
Generating Web Service client proxy code ......................................... 21
Consuming the Incident Reporting and Update API WSDL over
SSL ............................................................................... 21
Authenticating a client with the Incident Reporting and Update API
Web Service .......................................................................... 22
Java authentication example .................................................... 23
.NET authentication example .................................................... 23
About Incident Reporting and Update API Web Service
operations ............................................................................ 24
About incident detail types ....................................................... 26
Troubleshooting Incident Reporting and Update API client
applications ........................................................................... 31
Contents
Appendix A Incident Reporting and Update API Web Service
call reference ................................................................. 34
incidentList() ................................................................................ 34
Syntax ................................................................................. 34
Inputs .................................................................................. 35
Outputs ................................................................................ 36
Example ............................................................................... 36
Faults .................................................................................. 37
incidentDetail() ............................................................................. 37
Syntax ................................................................................. 38
Inputs .................................................................................. 38
Outputs ................................................................................ 39
Example ............................................................................... 40
Faults .................................................................................. 41
incidentBinaries() ......................................................................... 42
Syntax ................................................................................. 42
Inputs .................................................................................. 42
Example ............................................................................... 43
Faults .................................................................................. 45
listCustomAttributes() .................................................................... 45
Syntax ................................................................................. 45
Inputs .................................................................................. 45
Outputs ................................................................................ 46
Examples ............................................................................. 46
Faults .................................................................................. 46
listIncidentStatus() ........................................................................ 46
Syntax ................................................................................. 46
Inputs .................................................................................. 47
Outputs ................................................................................ 47
Example ............................................................................... 47
Faults .................................................................................. 47
updateIncidents() ......................................................................... 47
Syntax ................................................................................. 48
Inputs .................................................................................. 48
Outputs ................................................................................ 51
Example ............................................................................... 52
Faults .................................................................................. 53
incidentViolations() ....................................................................... 53
Syntax ................................................................................. 53
Inputs .................................................................................. 53
Output ................................................................................. 54
Example ............................................................................... 54
5Contents
Appendix B Base Incident Detail Types ................................................ 57
IncidentDetailType ........................................................................ 58
NetworkIncidentDetailType ............................................................. 65
DiscoverIncidentDetailType ............................................................ 67
EndpointIncidentDetailType ............................................................ 68
RestIncidentDetailType .................................................................. 69
Appendix C Extended Incident Detail Types ....................................... 71
About extended incident detail types ................................................ 71
Network component detail types ...................................................... 71
Discover component detail types ..................................................... 72
Endpoint component detail types ..................................................... 89
REST component detail types ......................................................... 93
Index ................................................................................................................... 104
6Contents
Introducing the Symantec
Data Loss Prevention
Incident Reporting and
Update API
This chapter includes the following topics:
■About updates to this guide
■About the Incident Reporting and Update API
■About Incident Reporting and Update API security
About updates to this guide
You can find the latest version of the Symantec Data Loss Prevention Incident Reporting and
Update API Developers Guide,Symantec Data Loss Prevention Incident Reporting and Update
API Examples, and the sample clients at the following link to the Symantec Support Center:
http://www.symantec.com/docs/DOC9264.
About the Incident Reporting and Update API
The Symantec Data Loss Prevention Incident Reporting and Update API enables a Web
Services developer to create applications that retrieve and update incident data that is stored
in a Symantec Data Loss Prevention deployment. You can use this API to integrate incident
data with other applications or systems to provide dynamic reporting, create a custom incident
1
Chapter
remediation process, or to support business processes that rely on Symantec Data Loss
Prevention incidents.
A Symantec Data Loss Prevention incident records all of the details that are associated with
a message that violated a Data Loss Prevention policy. A message in this context may refer
to an email message, an instant message, a file transfer, a copy or a print operation, an HTTP
request, or any other protocol message that you have configured Symantec Data Loss
Prevention to monitor. The data that is recorded in an incident includes the time the violation
occurred, the severity of the violation, and information about the originator and recipient of the
message that triggered the violation. Incidents also record data such as the text and headers
of the original message and files that were attached to the original message. Finally, an incident
may also contain historical data that is associated with efforts to remediate the incident in the
Enforce Server administration console. This historical data includes changes to the incident
severity or status and a list of any actions that were performed to help resolve or manage the
incident.
For example, you can use the API to correlate Symantec Data Loss Prevention incident data
with logs of the message sender’s telephone calls or network usage. Or, you can create
dashboard applications that integrate Symantec Data Loss Prevention incident data with data
from other systems, such as intrusion detection systems. By using the update functionality of
the API, you can create applications that perform custom remediation actions and then update
the results of the remediation in the Symantec Data Loss Prevention incident database. The
combined information from third-party systems and Symantec Data Loss Prevention, and the
ability to update the status of incidents, can provide valuable information to security experts
who are tasked with analyzing the data or with remediating security incidents.
The Incident Reporting and Update API is implemented as a Web Service that resides on the
Enforce Server. The Web Service conforms to the Simple Object Access Protocol (SOAP) 1.1
standard, and it advertises all available operations using a Web Services Description Language
(WSDL) document. You can use the WSDL document with compatible Web Services
development frameworks to generate certain client code automatically. Generated proxy code
for Java clients is also provided with your Symantec Data Loss Prevention installation.
About Incident Data Views
Symantec Data Loss Prevention provides incident data views that you can use to query incident
data from the Enforce Server database. Incident data views expose live up-to-date information
about Symantec Data Loss Prevention incidents.
The typical use case for incident data views is to query for unencrypted data in the database,
and then use the INCIDENT_ID to query for the encrypted incident data using the Symantec
Data Loss Prevention Incident Reporting and Update API.
For more information about Incident Data Views, contact Symantec Support.
8Introducing the Symantec Data Loss Prevention Incident Reporting and Update API
About the Incident Reporting and Update API
Features of the Incident Reporting and Update API
Using the Incident Reporting and Update API, you can:
■Retrieve incident lists
■Retrieve incident details
■Retrieve binary files associated with incidents
■Update incident details
■Retrieve incident details using batched requests
■Retrieve a list of incidents by date
■Access the list of custom attributes
■Access custom status values
■Retrieve highlighted matches for one or more incidents
Components of the Incident Reporting and Update API
The Symantec Data Loss Prevention Incident Reporting and Update API includes the
components described in Table 1-1.
Table 1-1 Incident Reporting and Update API components
DescriptionComponent
The WSDL document fully defines the request, response, and fault types that are provided by the
Incident Reporting and Update API Web Service. You can obtain the WSDL document directly from
an installed Enforce Server from the following URL:
https://<enforce_server>/ProtectManager/services/v2011/incidents?wsdl
(Where enforce_server is the IP address or host name of the Enforce Server.)
You use the WSDL document to generate code when you develop Incident Reporting and Update API
clients. The WSDL also provides the Web Service bindings to client applications at runtime.
See “Generating Web Service client proxy code” on page 21.
Web Service
Definition
Language
document
(WSDL)
9Introducing the Symantec Data Loss Prevention Incident Reporting and Update API
About the Incident Reporting and Update API
Table 1-1 Incident Reporting and Update API components (continued)
DescriptionComponent
The Incident Reporting and Update API XSD files describe the contents and structure of the XML
request and response documents that are associated with each Web Service call. The XSD files also
define the incident data types that you can use to represent incident details stored in the Enforce Server
database.
The XML schemas are available directly by the Incident Reporting and Update API WSDL. XSD files
are also available in the following JAR file on an Enforce Server host (line break added for legibility):
C:\Program
Files\Symantec\DataLossPrevention\EnforceServer\15.5\Protect\tomcat\lib\
incidentapi-2011-schema-2.0.jar
See “About incident detail types” on page 26.
XML Schema
Definitions
(XSD files)
Generated proxy (skeleton) Java code is available in the following JAR file on an Enforce Server host
(line break added for legibility):
C:\Program
Files\Symantec\DataLossPrevention\EnforceServer\15.5\Protect\tomcat\lib\
incidentapi-2011-generated-2.0.jar
Include this file in your Java CLASSPATH when you compile a Java-based Web Services client.
Proxy Java
classes
generated
from the
WSDL
You can download sample code that demonstrates Java and Microsoft .NET client implementations
of the Incident Reporting and Update API Web Service. The sample code is available at the Symantec
Support Center at the following URL:
http://symantec.com/docs/DOC9264
Example
Web Service
clients
Requirements for using the Incident Reporting and Update API
To use the Incident Reporting and Update API, you should be familiar with the process of
developing Web Services clients in a programming language of your choice. Although you
can develop SOAP-based Web Service clients in a variety of programming languages, Symantec
offers formal support only for Java 1.8 and .NET 4.5 and 4.6 implementations.
In addition, Symantec provides example reporting clients for both Java and .NET. The examples
are provided only for demonstration purposes. They are not supported for production use or
development, and Symantec provides no ongoing support to resolve bugs or add functionality
to the example applications. Symantec offers formal support only for the Incident Reporting
and Update API Web Service (WSDL implementation) and schema files, which provide the
core functionality of the Incident Reporting and Update API. Contact your Symantec sales
representative to obtain the example code.
10Introducing the Symantec Data Loss Prevention Incident Reporting and Update API
About the Incident Reporting and Update API
Symantec recommends that you use the Metro Web Service 2.2 framework or Microsoft .NET
4.5 or 4.6 framework to automatically generate code from the supplied WSDL document.
Because the Web Service itself was developed using the Metro Web Services 2.2 stack, you
may choose to use the same stack to speed client development.
See “Generating Web Service client proxy code” on page 21.
About localization of system-defined fields
The Incident Reporting and Update API Web Service localizes all system-defined fields returned
in Web Service responses. However, user-defined content such as custom attribute fields are
not localized either in the Enforce Server administration console or the Incident Reporting and
Update API Web Service. Client implementations must consider the possibility of non-localized
data when transforming or displaying user-defined content in incident data results.
About Incident Reporting and Update API security
The Incident Reporting and Update API Web Service requires HTTPS for communication with
client applications. The underlying SSL transport provides end-to-end encryption of all data
transmitted between the Web Service and authorized clients. The Web Service performs no
additional encryption for the incident data or binary data contained in responses.
The Incident Reporting and Update API Web Service authenticates each client request using
the HTTP basic authentication scheme. Client applications must supply the credentials of a
valid Symantec Data Loss Prevention user in the HTTP authentication headers of each request
to the Web Service. You must create this user account using the Enforce Server administration
console before accessing the Web Service.
Note: Symantec Data Loss Prevention authenticates all Incident Reporting and Update API
clients using password authentication. If you configure Symantec Data Loss Prevention to use
certificate authentication, any user account that is used to access the Incident Reporting and
Update API Web Service must have a valid password in the Enforce Server administration
console configuration.
See “Creating a user and role for an Incident Reporting and Update API client” on page 16.
An authenticated user is authorized to access the Incident Reporting and Update API Web
Service if the user is assigned to a role where one of the following user privileges is granted:
■Incident Reporting—allows read-only access to incident data
■Incident Update—allows updates to incident data
See “Creating a user and role for an Incident Reporting and Update API client” on page 16.
11Introducing the Symantec Data Loss Prevention Incident Reporting and Update API
About Incident Reporting and Update API security
Implementing an Incident
Reporting and Update API
client
This chapter includes the following topics:
■About Incident Reporting and Update API client implementations
■Implementing an Incident Reporting and Update API client
■Installing a development system
■Creating a user and role for an Incident Reporting and Update API client
■Creating a saved report for an Incident Reporting and Update API client
■Generating Web Service client proxy code
■Authenticating a client with the Incident Reporting and Update API Web Service
■About Incident Reporting and Update API Web Service operations
■Troubleshooting Incident Reporting and Update API client applications
About Incident Reporting and Update API client
implementations
The Incident Reporting and Update API provides a Web Service interface that clients can use
to retrieve and update incident data. Before a client can interact with the Incident Reporting
and Update API Web Service, the following items must be configured in the Enforce Server
administration console:
2
Chapter
■A user account that is assigned to a role that has permission to access the Incident
Reporting and Update API Web Service.
See “Creating a user and role for an Incident Reporting and Update API client” on page 16.
■A saved report that queries Symantec Data Loss Prevention incidents based on the
constraints and filters you specify. This report must be available to the Incident Reporting
and Update API user account that accesses the Web Service.
See “Creating a saved report for an Incident Reporting and Update API client” on page 19.
A Web Service client provides the credentials of the Enforce Server user account in each
request that it sends to the Incident Reporting and Update API Web Service. The Web Service
authenticates the credentials, and then authorizes or denies the request based on whether
the authenticated user has privileges to access the Web Service.
About reporting clients
To retrieve incident data, a reporting Web Service client typically begins by requesting a list
of incidents that are specified by a saved incident report that was previously defined in the
Enforce Server administration console. Although the saved incident report may return a very
large list of incidents, the Web Service client can request a subset of incidents by specifying
a date in the Web Service call. The Web Service only returns incidents that were created after
this specified date. You can also apply filters to the saved incident report to further limit the
incidents returned. As a best practice, a Web Service client should log the time of its most
recent incident list request. Each Web Service request for an incident list should retrieve only
those incidents that were created since the time of the last request.
After obtaining a list of incident IDs, a Web Service client can submit further requests to obtain
detailed incident data for a specific incident. The client can request these incidents individually,
or the client can make a Web Service call that uses a "batched" approach where the client
requests incident data for multiple incidents in a single call. When you request incident IDs in
batches, you can improve performance of the client. Symantec recommends that you use
batches of 50 to 100 incidents for best performance. The client can also request to retrieve
the full binary data associated with a given incident (the complete message, file, or attachment
that generated the incident). The complete list of Incident Reporting and Update API Web
Service operations, as well as error messages, are defined in the WSDL document.
See “Implementing an Incident Reporting and Update API client” on page 14.
The Incident Reporting and Update API Web Service returns incident lists, incident details,
and incident binaries to clients using XML-formatted SOAP 1.1 messages. Incident details
reference a common XML schema and conform to specific incident types based on the
Symantec Data Loss Prevention product and product component that generated the incident.
See “About incident detail types” on page 26.
13Implementing an Incident Reporting and Update API client
About Incident Reporting and Update API client implementations
About update clients
To update incident data, an Incident Reporting and Update API client application makes a
Web Service call that contains one or more batches of incidents to be updated. Each batch
specifies a list of incident identifiers and the fields and values that should be updated for those
incidents. Using this call, you can update multiple incidents with the same data.
You can update the following incident fields using the Incident Reporting and Update API:
■Incident severity
■Incident status
■Custom attribute values
■Data owner data structure
■Notes/Comments data structure
■Remediation status
■Remediation location
The response to an update call includes information on the success or failure of the updates.
It is important to consider the size of the batches to maximize performance of the API. Including
more incidents in a batch increases the performance of the API. Making a Web Service call
to update a single incident is the least efficient way to update an incident. For best performance
when updating incident data, Symantec recommends that each batch contain between 50 to
500 incident IDs.
Implementing an Incident Reporting and Update API
client
The following table summarizes the steps that are involved in implementing an Incident
Reporting and Update API Web Service client. See the associated sections for more details
about each step.
Table 2-1 Implementing an Incident Reporting and Update API client
DescriptionActionStep
See “Installing a development system” on page 15.Install a development system.1
See “Creating a user and role for an Incident Reporting and Update
API client” on page 16.
Create an Incident Reporting and
Update API user and role.
2
14Implementing an Incident Reporting and Update API client
Implementing an Incident Reporting and Update API client
Table 2-1 Implementing an Incident Reporting and Update API client (continued)
DescriptionActionStep
See “Creating a saved report for an Incident Reporting and Update
API client” on page 19.
Create a saved report.
(This step is required only when
the client needs to retrieve a list of
incident IDs.)
3
See “Generating Web Service client proxy code” on page 21.
For Java clients, you may use the generated proxy code that is
available in the following JAR file on an Enforce Server host (line
break added for legibility):
c:\Symantec\DataLossPrevention\EnforceServer\15.5\Protect\
tomcat\lib\incidentapi-2011-generated-2.0.jar
Include this file in your Java CLASSPATH when you compile a
Java-based Web Services client.
Generate client code from the
Incident Reporting and Update API
Web Service WSDL.
4
See “About Incident Reporting and Update API Web Service
operations” on page 24.
Implement calls to the Incident
Reporting and Update API Web
Service.
5
See “Troubleshooting Incident Reporting and Update API client
applications” on page 31.
Troubleshoot the client
implementation.
6
Installing a development system
To develop and test your client implementations of the Incident Reporting and Update API,
set up a test installation of Symantec Data Loss Prevention. You can use a single-tier, two-tier,
or three-tier installation. A single-tier Symantec Data Loss Prevention installation, where the
Enforce Server, detection server, and the Oracle database are deployed on a single computer,
is sufficient for development purposes.
See the Symantec Data Loss Prevention Installation Guide at
http://www.symantec.com/docs/DOC9257 for more information.
To verify client functionality, you must populate the development system with example incident
data.
A SOAP development tool can be useful during deveolpment of client applications. A tool such
as soapUI can consume the WSDL and generate XML request documents automatically. The
tool can send those requests to the Web Service and displays the XML response document.
See http://www.soapui.org/.
15Implementing an Incident Reporting and Update API client
Installing a development system
Note: Symantec does not recommend testing Web Service clients against a live production
server, or using copies of live incident data. Doing so increases the possibility of exposing
confidential data (incident data and user credentials) on unprotected development and test
computers, or of incorrectly updating your production incident database.
Creating a user and role for an Incident Reporting and
Update API client
You must use the Enforce Server administration console to create a Web Service user and
role before you can connect to the Web Service from a client application.
To create an Incident Reporting and Update API Web Service role and user
1Log on to the Enforce Server administration console as an Administrator.
2Select System > Login Management > Roles.
3Click Add Role.
4Type a name for the new role in the Name field. For example, type “Incident API Client
Role.”
16Implementing an Incident Reporting and Update API client
Creating a user and role for an Incident Reporting and Update API client
5In the User Privileges section of the screen, select items as described in the following
table.
DescriptionItem
Select View, and then select the incident types
that the Web Service role can view or update. If
Incidents: View
you do not select a particular incident type, the
Web Service does not return incident details of
that type to clients that use this role and clients
cannot update incidents of that type.
Select the Remediate Incidents privilege.Incidents: Actions
Select one or both of the following two user
privileges:
Incidents: API
Incident Reporting — enables Web Services
clients to retrieve incident details using the
Incident Reporting and Update API.
Incident Update—enables Web Services clients
to update incident details using the Incident
Reporting and Update API.
Select all of the attributes that you want to include
in incident detail responses for this role.
Incidents: Display Attributes
Note: If your client implementation uses the
incidentBinaries() operation, select the
Attachments/Files permission.
17Implementing an Incident Reporting and Update API client
Creating a user and role for an Incident Reporting and Update API client
DescriptionItem
Custom attributes are optional data fields that
you can use to store supplemental information
about an incident. Your organization may use
custom attributes to assist in the workflow for
remediating or evaluating incidents.
Select View for each custom attribute that you
want to include in incident detail responses for
this role or select View All to include all custom
attributes.
Select Edit for each custom attribute that you
want to allow a Web Service client to update or
select Edit All to allow updates to all custom
attributes.
You can use the listCustomAttributes()
method of Incident Reporting and Update API to
retrieve a list of custom attributes that have been
defined in the deployment. See
“listCustomAttributes()” on page 45.
See the Symantec Data Loss Prevention
Administration Guide at
http://www.symantec.com/docs/DOC9261 for
more information about custom attributes.
Incidents: Custom Attributes
Note: Role-based access privileges provide a way to limit the results of a Web Service
incident list request or incident detail request. For example, the Incident Reporting and
Update API WSDL does not enable a client to retrieve only Endpoint-related incident IDs
when requesting an incident list. However, you can use the User Privileges selection to
limit the Web Service user role to view only Endpoint-related incidents. Alternately, you
can create a saved report that returns only Endpoint-related incidents, and use that report
to retrieve an incident list.
See “Creating a saved report for an Incident Reporting and Update API client” on page 19.
6(Optional) Click the Incident Access tab to set additional conditions that limit the incidents
that Incident Reporting and Update API clients may access.
7Click Save.
8Select System > Login Management > DLP Users.
9Click Add User.
18Implementing an Incident Reporting and Update API client
Creating a user and role for an Incident Reporting and Update API client
10 Type the credentials for the new user in the Name,Password, and Re-enter Password
fields.
Note: Symantec Data Loss Prevention authenticates all Incident Reporting and Update
API clients using password authentication. If you configure Symantec Data Loss Prevention
to use certificate authentication, any user account that is used to access the Incident
Reporting and Update API Web Service must have a valid password.
11 In the Roles section of the screen, select the new role you created in step 4. For example,
select “Incident API Client Role.”
12 Select the same Incident API Client Role role in the Default Role menu.
13 Click Save.
Creating a saved report for an Incident Reporting and
Update API client
Clients of the Incident Reporting and Update API Web Service request a list of incident IDs
by specifying a saved report ID. Use the Enforce Server administration console to create one
or more saved reports. The saved report defines a collection of incident IDs that a Web Service
client can retrieve with a call to the incidentList method. You can create multiple saved
reports as necessary for your client application.
See “About Incident Reporting and Update API Web Service operations” on page 24.
The saved report that you create must return an incident list. You cannot access a saved
dashboard or summary report using a Web Service client. You cannot retrieve a system-defined
incident list using the Incident Reporting and Update API. However, you can use a
system-defined incident list to generate a new saved report.
The instructions that follow describe how to create a new saved report for use with the Incident
Reporting and Update API.
19Implementing an Incident Reporting and Update API client
Creating a saved report for an Incident Reporting and Update API client
To create a saved report for an Incident Reporting and Update API Web Service client
1Logon to the Enforce Server administration console as the Incident Reporting and Update
API Web Service user.
Note: The saved report must be accessible to the Incident Reporting and Update API Web
Service user.
See “Creating a user and role for an Incident Reporting and Update API client” on page 16.
2Select Incidents > Incident Reports.
3Select an existing incident list from the list of available reports. You may select a
system-defined incident list, such as Incidents – All, as the basis for the new report.
4Optionally, use the Filter and Severity controls report to limit the incident IDs that the
report returns.
5Click Advanced Filters & Summarization.
6In the Summarize By menu, verify that <no primary summary selected> and <no
secondary summary selected> are both chosen. You cannot access a summary report
using the Incident Reporting and Update API Web Service.
7Optionally, click Add filter and add one or more advanced filters to limit the incident IDs
that the report returns.
Note: Role-based access privileges may further limit the results that are returned from
the Incident Reporting and Update API Web Service.
See “Creating a user and role for an Incident Reporting and Update API client” on page 16.
8Select Report > Save As.
9Type a name for the report in the Name field, and an optional description in the Description
field.
10 Click Save.
The new saved report appears under the Saved Reports heading in the left pane.
11 To determine the ID of the saved report, move your mouse pointer over the report name.
The tool tip displays the report ID and name of the report. For example, if the tool tip
displays “View Report 83: ‘Incident Reporting and Update API Saved Report’,” a Web
Service client can request the incident list by specifying “83” in the incidentList call.
The status bar of your browser also displays the saved report ID at the end of the link
name when you place the pointer over the saved report name.
20Implementing an Incident Reporting and Update API client
Creating a saved report for an Incident Reporting and Update API client
Generating Web Service client proxy code
Symantec recommends that you use a Web Service development framework when building
an Incident Reporting and Update API client application. Using a development framework
enables you to automatically generate Web Service skeleton code for Web Service calls and
data types. The skeleton code is generated directly from the Incident Reporting and Update
API WSDL document and supporting schema documents. You supply the WSDL as a URL
served by your development Symantec Data Loss Prevention server installation.
Although you can use a variety of frameworks to generate client code, Symantec recommends
using Metro Web Services 2.2 or another environment that generates Java API for XML Web
Services (JAX-WS) style code artifacts, such as the Java EE SDK. A JAR file that contains
generated Java skeleton code is available on the Enforce Server host.
See “Components of the Incident Reporting and Update API” on page 9.
Microsoft .NET developers should use the .NET 4.5 or 4.6 runtime, which supports the Windows
Communication Foundation (WCF) API for Web Services development. The Incident Reporting
and Update API Web Service was developed using Metro Web Services, which provides full
interoperability with Microsoft .NET WCF clients. A generated proxy class file is available with
the Incident Reporting and Update API example client distribution. The sample code is available
at the Symantec Support Center at the following URL:
http://symantec.com/docs/DOC9264
The framework you choose will generally provide both a command-line utility and build script
support for consuming a WSDL document and schema to generate code. For example, the
Java EE SDK includes the wsimport command-line utility for generating Java code. See your
framework documentation for details about generating skeleton code from a WSDL file.
Consuming the Incident Reporting and Update API WSDL over SSL
The Incident Reporting and Update API WSDL document is available from the Enforce Server
at the following URL:
https://<enforce server>/ProtectManager/services/v2011/incidents?wsdl
Where enforce server is the host name or IP address of the Enforce Server.
The Enforce Server administration console requires SSL transport for all communication. Any
utility that you use to consume the WSDL and generate skeleton code must first be able to
negotiate the SSL connection with the Enforce Server. For more information about using
certificates with Symantec Data Loss Prevention, see "About configuring certificate
authentication" in the Symantec Data Loss Prevention Administration Guide.
If your Symantec Data Loss Prevention deployment already uses certificate authentication,
use a Web browser to export the Enforce Server certificate. You can then import that certificate
21Implementing an Incident Reporting and Update API client
Generating Web Service client proxy code
to a keystore that is used in the client environment. The Enforce Server keystore is in the
following location on the Enforce Server host:
c:\Symantec\DataLossPrevention\EnforceServer\15.5\Protect\tomcat\conf\.keystore
Configure your client to use the Enforce Server keystore file. For example, Java utilities such
as wsimport can specify the keystore location using command-line options.
For example (line breaks added for legibility):
-Djavax.net.ssl.keyStore=/opt/Symantec/DataLossPrevention/EnforceServer/
15.5/Protect/tomcat/conf/.keystore
-Djavax.net.ssl.keyStorePassword=protect
-Djavax.net.ssl.trustStore=/opt/Symantec/DataLossPrevention/EnforceServer/
15.5/Protect/tomcat/conf/.keystore
-Djavax.net.ssl.trustStorePassword=protect
See your development framework documentation for more information.
Authenticating a client with the Incident Reporting
and Update API Web Service
The Incident Reporting and Update API Web Service authenticates each client request using
the HTTP Basic authentication scheme. Client applications must supply the credentials of a
valid Symantec Data Loss Prevention user in the HTTP authentication headers of each request
to the Web Service. Each request must be made over an SSL connection to the Incident
Reporting and Update API Web Service.
To authenticate using HTTP basic authentication
1Obtain user credentials interactively or using a configuration file.
2Validate SSL certificates as necessary for HTTPS communication with the Web Service.
3Create a binding to the Web Service port, specifying HTTP Basic authentication as needed.
4Add the user credentials to the Web Service connection.
The Web Service returns an authenticationFailedFault if the Enforce Server cannot
authenticate using the supplied credentials. For security reasons, authenticationFailedFault
provides no details about why the authentication failed.
The exact method for performing these tasks depends on the programming language in which
you develop the Web Service client. The following code examples show how to add
authentication headers and use HTTP Basic authentication in Java and .NET clients. The
examples use hard-coded user credentials for simplicity.
The code examples do not show a method for validating SSL certificates.
22Implementing an Incident Reporting and Update API client
Authenticating a client with the Incident Reporting and Update API Web Service
The full Java and .NET example clients simplify the HTTPS connection process by bypassing
SSL certificate validation. See the full code for the example clients for more information. The
sample code is available at the Symantec Support Center at the following URL:
http://symantec.com/docs/DOC9264
Java authentication example
Java clients add user credentials to the request context of the Web Service port binding. The
following example shows the Java client methods used to add required authentication headers:
// Define user credentials.
//
String client_username = "WS_Client";
String client_password = "welcome";
// Create the Incident Reporting and Update API service.
//
URL serviceUrl = new URL("https://EnforceMachineHostName/IP/ProtectManager/services/v2011/incidents?wsdl");
QName serviceNamespace = new QName("http://www.company.com/v2011/enforce/webservice/incident",
"IncidentService"));
IncidentService service = new IncidentService(serviceUrl, serviceNamespace);
// Bind credentials to the service port.
//
IncidentServicePortType servicePort = service.getIncidentServicePort();
BindingProvider portBP = (BindingProvider) servicePort;
portBP.getRequestContext().put(BindingProvider.USERNAME_PROPERTY, client_username);
portBP.getRequestContext().put(BindingProvider.PASSWORD_PROPERTY, client_password);
.NET authentication example
.NET clients use Microsoft Windows Communication Foundation (WCF) HTTP binding methods
to supply basic HTTP authentication headers with the Web Service request. The following
example shows the Microsoft .NET client methods used to add required authentication headers:
// Define user credentials.
//
String client_username = "WS_Client";
String client_password = "welcome";
// Prepare HTTP bindings with username/password
// basic authentication. Init incident reporting
23Implementing an Incident Reporting and Update API client
Authenticating a client with the Incident Reporting and Update API Web Service
// service port
//
// An Example of the URL is as follows
this.url = "https://EnforceMachineHostName/IP/ProtectManager/services/incidents?wsdl";
EndpointAddress epAddress = new EndpointAddress(this.url);
BasicHttpBinding basicAuthBindings = setupBasicAuthentication();
client = new IncidentServicePortTypeClient(basicAuthBindings, epAddress);
client.ClientCredentials.UserName.UserName = client_username;
client.ClientCredentials.UserName.Password = client_password;
IEndpointBehavior behavior = new HttpBasicAuthenticationEndpointBehavior();
client.Endpoint.Behaviors.Add(behavior);
// connect to the reporting API service
//
client.Open();
About Incident Reporting and Update API Web Service
operations
Table 2-2 lists the operations that the Incident Reporting and Update API Web Service supports
for retrieving and updating incident data.
Each operation takes a request that encapsulates arguments for the operation. A successful
request to the Web Service returns a corresponding response document that contains the
incident data or the status of update operations. Failed operations return one of several possible
faults.
See “Troubleshooting Incident Reporting and Update API client applications” on page 31.
24Implementing an Incident Reporting and Update API client
About Incident Reporting and Update API Web Service operations
Table 2-2 Incident Reporting and Update API service operations
DetailsDescriptionOperation
See “incidentList()”
on page 34.
The incidentList() method returns a list of incident
IDs described by a saved report. The client specifies the
saved report ID to retrieve and a date value. The date
value limits the list of incidents to those created after the
specified date. A client application generally begins with
a call to incidentList(), and wraps the returned
values in an array or other container to work with the
incident IDs. The application can then use either the
incidentDetails() or incidentBinaries() Web
Service calls to retrieve additional details about one or all
of the returned incident IDs. The application can also use
the updateIncidents() method to update incident
details.
incidentList()
See “incidentDetail()”
on page 37.
See “About incident
detail types” on page 26.
The incidentDetail() method returns the details of
a single Symantec Data Loss Prevention incident, such
as its creation date, severity, and status. A client can use
the fields of the response document as-is, or the client
may cast the response document into a more specific
incident detail type.
incidentDetail()
See “incidentBinaries()”
on page 42.
The incidentBinaries() method returns the binary
data of a single Symantec Data Loss Prevention incident,
such as the original message that generated the incident
or files that were attached to the original message.
incidentBinaries()
See “updateIncidents()”
on page 47.
The updateIncidents() method allows a client
program to update various attributes of incident data. The
client specifies one or more batches of incident IDs and
a set of attributes and values to update for each batch. A
client can update incident severity, incident status, custom
attributes, data owner details, notes, remediation status,
and remediation location.
updateIncidents()
See
“listCustomAttributes()”
on page 45.
The listCustomAttributes() method returns a list
of custom attributes that are defined in the Symantec Data
Loss Prevention deployment.
listCustomAttributes()
See “listIncidentStatus()”
on page 46.
The listIncidentStatus() method returns a list of
all custom status values that are defined in the Symantec
Data Loss Prevention deployment.
listIncidentStatus()
25Implementing an Incident Reporting and Update API client
About Incident Reporting and Update API Web Service operations
Table 2-2 Incident Reporting and Update API service operations (continued)
DetailsDescriptionOperation
See “incidentViolations()”
on page 53.
The incidentViolations() operation takes the
incidentID as input and returns the text-based content for
each match in the incident. In the Enforce Server
administration console, this content appears as highlighted
matches for the incident.
incidentViolations()
About incident detail types
A successful request to the incidentDetail() operation returns a single XML stanza of the
type IncidentDetailType. The stanza describes the basic characteristics that are shared by
all Symantec Data Loss Prevention incidents. This includes the unique ID of the incident, the
date on which the incident was created, the severity and status of the incident, the policy and
rule that were violated, and so forth.
Incidents that are created by different Symantec Data Loss Prevention products contain
additional information that is unique to the product group. For example, Symantec Data Loss
Prevention network products (Network Monitor and Network Prevent) may contain a message
header or recipient field. Network Discover incidents include the name of the scan that generated
the incident, and may include the name of a file that generated a policy violation.
The Incident Reporting and Update API XML schema defines product-specific incident detail
types by extending the base IncidentDetailType with additional fields. Six product incident
detail types are defined:
Products that generate this incident typeProduct incident detail type
■Network Monitor
■Network Prevent for Email
■Network Prevent for Web
NetworkIncidentDetailType
■Endpoint Discover
■Endpoint Prevent
EndpointIncidentDetailType
■Network Discover
■Network Protect
DiscoverIncidentDetailType
■Cloud Storage DiscoverDiscoverBoxCrawlerIncidentDetailType
■Cloud Service ConnectorRestDARIncidentDetailType
■Cloud Service ConnectorRestDIMIncidentDetailType
26Implementing an Incident Reporting and Update API client
About Incident Reporting and Update API Web Service operations
Figure 2-1 shows the base fields defined in IncidentDetailType and the extension fields
defined in the Network Endpoint, and Discover incident detail types; Figure 2-2 shows the
REST DAR incident detail types; and Figure 2-3 shows the REST DIM incident detail types.
To work with the additional fields of a product incident detail type, a client application can cast
the IncidentDetailType into a more specific product incident detail type. The messageSource
field in IncidentDetailType provides a key that indicates the Symantec Data Loss Prevention
product that generated the incident.
Figure 2-1 Hierarchy of product incident detail types (not including REST incidents)
27Implementing an Incident Reporting and Update API client
About Incident Reporting and Update API Web Service operations
Figure 2-2 Hierarchy of product incident detail types (including REST DAR incidents)
IncidentDetailType
-incidentId
-incidentCreationDate
-detectionDate
-severity
-status
-messageSource
-messageType
-policy
-violatedPolicyRule
-otherViolatedPolicy
-blockedStatus
-matchCount
-ruleViolationCount
-detectionServer
-customAttributeGroup
-incidentHistor y
-dataOwner
RestDARIncidentDetailType
-activityCount
-applicationInstanceID
-applicationName
-applicationReportName
-authSender
-creatorID
-dataType
-description
-deviceIsTrusted
-deviceOS
-deviceType
-docExposedAllInternal
-docExposedCount
-docExposedPublic
-docInternal
-documentId
-documentType
-environment
-fileCreated
-fileFolder
-fileTag
-httpBrowser
-httpCookies
-httpMethod
-httpUrl
-httpUserAgent
-incidentLongID
-insideOfficeLocation
-lastAccessed
-last modified
-linkDocExposure
-linkIncident
RestDARIncidentDetailType
(continued)
-linkServiceApplication
-linkUba
-linkUserExposures
-locationCoordsLatitude
-locationCordsLongitudelogId
-message Date
-messageBodyContent
workProtocol
-networkSenderIP
-networkSender Port-
-originator
-parentFolderIdentifier
-personal
-recipient
-regionCountry
-requestId
-serviceClassification
-serviceScore
-sharepoint
-sharingUrl
-siteClassification
-threatScore
-transactionID
-uniqueMessageId
-unmanaged
-userActivityType
-userID
-userInternal
-userName
28Implementing an Incident Reporting and Update API client
About Incident Reporting and Update API Web Service operations
Figure 2-3 Hierarchy of product incident detail types (including REST DIM incidents)
-incidentId
-incidentCreationDate
-detectionDate
-severity
-status
-messageSource
-messageType
-policy
-violatedPolicyRule
-otherViolatedPolicy
-blockedStatus
-matchCount
-ruleViolationCount
-detectionServer
-customAttributeGroup
-incidentHistor y
-dataOwner
IncidentDetailType
RestDIMIncidentDetailType
-activityCount
-applicationInstanceID
-applicationName
-applicationReportName
-authSender
-creatorID
-dataType
-description
-deviceIsTrusted
-deviceOS
-deviceType
-docExposedAllInternal
-docExposedCount
-docExposedPublic
-docInternal
-documentId
-documentType
-environment
-httpBrowser
-httpCookies
-httpMethod
-httpUrl
-httpUserAgent
-incidentLongID
-insideOfficeLocation
-linkDocExposure
-linkIncident
-linkServiceApplication
-linkUba
RestDIMIncidentDetailType
continued
-linkUserExposures
-locationCoordsLatitude
-locationCordsLongitude
-logId
-messageBodyContent
-message Date
-networkDirection
-networkProtocol
-networkSenderIP
-networkSenderPort
-originator
-parentFolderIdentifier
-personal
-recipient
-regionCountry
-requestId
-serviceClassification
-serviceScore
-sharepoint
-siteClassification
-threatScore
-transactionID
-uniqueMessageId
-unmanaged
-userActivityType
-userID
-userInternal
-userName
29Implementing an Incident Reporting and Update API client
About Incident Reporting and Update API Web Service operations
Within a particular Symantec Data Loss Prevention product, incident details may be further
differentiated by the product component that detected the incident or by the protocol used to
transmit the original message. For example, a user can generate an incident by attempting to
copy sensitive data to the clipboard or by sending sensitive data from an email application.
These two cases create different kinds of incident data. In the first example, the incident data
includes information about the application the user was using when they tried to copy data to
the clipboard. In the second example, the incident data records the subject of the email message
that generated the incident.
To account for these differences, the Incident Reporting and Update API XML schema further
extends the product group incident types into product component incident detail types. The
messageType field in the IncidentDetailType provides a key that identifies a valid component
type for the incident. Based on the messageType, you can cast to the most specialized
component type or to the associated product category type as needed.
Figure 2-4 shows the product component incident detail types that extend the five product
group incident types. (Note that the attributes for individual product and component types are
omitted for space considerations.)
30Implementing an Incident Reporting and Update API client
About Incident Reporting and Update API Web Service operations
Figure 2-4 Hierarchy of component incident detail types
Troubleshooting Incident Reporting and Update API
client applications
Each of the Incident Reporting and Update API operations can potentially return one of several
faults to indicate why an operation failed. As a best practice, client applications should display
or log any faults that cannot be resolved internally by the application code.
For example, if an application prompts the user to enter credentials or individual incident IDs,
the application should notify the user when either an authenticationFailedFault or
incidentNotFoundFault occurs. If the application uses hard-coded credentials or derives
incident IDs from incidentList requests, the application may instead log these faults to an
application-specific log file.
In addition to the faults that are provided by the Incident Reporting and Update API, these
Symantec Data Loss Prevention operational log files store additional information about the
behavior of the Web Service implementation:
31Implementing an Incident Reporting and Update API client
Troubleshooting Incident Reporting and Update API client applications
■webservice_access.log records both successful attempts and failed attempts to access
the Incident Reporting and Update API Web Service. This log file records many of the same
authentication error conditions that are returned to Web Service clients as API faults.
However, the log file aggregates this information for all clients that access the Incident
Reporting and Update API Web Service on the Enforce Server. webservice_access.log
also logs successful client requests with:
■Time of the request
■Name of the user who made the request
■Success or failure of the request
■Type of request
■Amount of time taken to complete the request
■webservices_soap.log records the entire SOAP request and response for most requests
to the Incident Reporting and Update API Web Service. The log records all requests and
responses except responses to incident binary requests. Although this log also records
Incident Reporting and Update API faults, any Java exceptions generated by the Enforce
Server are logged to the Tomcat log file.
webservices_soap.log is not created by default. To begin logging to this file, edit the
c:\Program
Files\Symantec\DataLossPrevention\EnforceServer\15.5\Protect\config\ManagerLogging.properties
(Windows) or /opt/Symantec/DataLossPrevention/ Enforce
Server/15.5/Protect/config/ManagerLogging.properties (Linux) file to set the
com.vontu.enforce.reportingapi.webservice.log.
WebServiceSOAPLogHandler.level property to INFO.
Note: The webservices_soap.log file includes sensitive information in the response details.
Symantec recommends securing these log files to avoid loss of the sensitive information
they include. Symantec also recommends cleaning up these log files after you have finished
troubleshooting.
In addition to these operational log files, the following log files may contain additional information
about the health or availability of the Web application that implements the Incident Reporting
and Update API Web Service:
■manager_operational.log is a Symantec Data Loss Prevention operational log file that
records lifecycle and system events that are associated with the Enforce Server. The
Incident Reporting and Update API Web Service works with the Enforce Server to provide
incident data through SOAP requests.
See “Operational Log Files and Codes” in the Symantec Data Loss Prevention Administration
Guide for more information about this log file.
32Implementing an Incident Reporting and Update API client
Troubleshooting Incident Reporting and Update API client applications
■The Tomcat server log file may also contain information about failed deployment for the
Symantec Data Loss Prevention Web applications. Consult this log file last, after you first
examine the Incident Reporting and Update API faults, Web Service operational logs, and
Symantec Data Loss Prevention operational logs. The Enforce Server stores the local
Tomcat log file in the following location:
■Windows (line break added for legibility):
c:\ProgramData\Symantec\DataLossPrevention\EnforceServer\15.5\Protect\logs\
tomcat\localhost.timestamp.log
■Linux:
/var/log/Symantec/DataLossPrevention/EnforceServer/15.5/tomcat/localhost.timestamp.log
The following troubleshooting task pertains to Windows 2008 R2 operating systems running
a .NET client where FIPS mode is being used on the server.
If a client is trying to connect to a server installed in FIPS mode and during execution the
system throws a connection error that is related to the TLS version, you need to make the
following changes to the Windows 2008 R2 computer where you are running the client:
■Set the registry setting to FIPS:
HKLM\System\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled
This registry value reflects the current FIPS setting. If this setting is enabled, the value is
1. If this setting is disabled, the value is 0. Enable FIPS by setting the value to 1 if it is 0.
■Select Run > Local Security Policy > Local Policies > Security Options > System
cryptography.
Use FIPS compliant algorithms for encryption, hashing and signing to 'enabled'.
Refer to the .NET example client that is available at the Symantec Support Center at the
following URL:
http://symantec.com/docs/DOC9264
33Implementing an Incident Reporting and Update API client
Troubleshooting Incident Reporting and Update API client applications
Incident Reporting and
Update API Web Service call
reference
This appendix includes the following topics:
■incidentList()
■incidentDetail()
■incidentBinaries()
■listCustomAttributes()
■listIncidentStatus()
■updateIncidents()
■incidentViolations()
incidentList()
incidentList()—returns a list of incident IDs by executing a saved report on the Enforce
Server.
Syntax
IncidentListResponse = IncidentServicePortType.incidentList(IncidentListRequest);
A
Appendix
Inputs
This call takes a single IncidentListRequest type as its argument. IncidentListRequest
encapsulates the ID of the saved report to execute on the Enforce Server and the date used
to constrain the list of incident IDs returned by the call.
The following table describes the IncidentListRequest fields.
Table A-1 IncidentListRequest instance variables
DescriptionTypeName
Specifies the ID of the saved report to
execute on the Enforce Server. This
report must be created using the
Enforce Server administration console
before executing the Web Service call.
There is no mechanism to create a
saved report by the Incident Reporting
and Update API Web Service.
See “Creating a saved report for an
Incident Reporting and Update API
client” on page 19.
intsavedReportId
35Incident Reporting and Update API Web Service call reference
incidentList()
Table A-1 IncidentListRequest instance variables (continued)
DescriptionTypeName
Constrains the list of returned incident
IDs to include only incidents that were
created after the
incidentCreationDateLaterThan
date.
A null value retrieves no reports.
As a best practice, client applications
should record the creation time of the
latest incident they retrieved and use
that time to retrieve only newly created
incident IDs.
If you need to further constrain the list
of returned incident IDs, either:
■Customize filters for the saved
report that you reference, or
■Configure role-based access
controls for the Web Service client
user to limit the type of incidents
that can be viewed.
See “Creating a user and role for an
Incident Reporting and Update API
client” on page 16.
dateTimeincidentCreationDateLaterThan
Outputs
Returns an IncidentListResponse object that encapsulates a list of incident IDs. The list is
a subset of the IDs described by the saved report, constrained by the value of the
incidentCreationDateLaterThan instance variable and any role-based access controls
applied to the Web Service user.
See “Creating a saved report for an Incident Reporting and Update API client” on page 19.
See “Creating a user and role for an Incident Reporting and Update API client” on page 16.
Example
The following example shows how a Java client retrieves a list of incidents with
incidentList().
36Incident Reporting and Update API Web Service call reference
incidentList()
Note: The Java code in this section is for instructional purposes only and does not demonstrate
a complete client implementation. The sample code is available at the Symantec Support
Center at the following URL:
http://symantec.com/docs/DOC9265
IncidentListRequest request = new IncidentListRequest();
XMLGregorianCalendar setDate = null;
GregorianCalendar c = new GregorianCalendar();
c.setTime(incidentDate);
setDate = DatatypeFactory.newInstance().newXMLGregorianCalendar(c);
request.setIncidentCreationDateLaterThan(setDate);
request.setSavedReportId(Integer.parseInt(reportId));
try
{
IncidentServicePortType clientPort = client.getPortClient();
IncidentListResponse response=clientPort.incidentList(request);
List<Integer> incidentIds = response.getIncidentId();
for(int incidentid:incidentIds)
{
System.out.println("Incident ID: " + incidentid);
}
}
Faults
The incidentList call can return the following general faults:
■AuthenticationFailedFault
■AuthorizationFailedFault
■ServiceErrorFault
If a client specifies an invalid saved report ID, the error is captured in a ServiceErrorFault.
The ServiceErrorFault also captures any unknown runtime errors.
incidentDetail()
incidentDetail()—requests the details of a specified incident.
37Incident Reporting and Update API Web Service call reference
incidentDetail()
Syntax
IncidentDetailResponse = IncidentServicePortType.incidentDetail(IncidentDetailRequest);
Inputs
This call takes a single IncidentDetailRequest type as its argument. IncidentDetailRequest
encapsulates a list of incident IDs. The response returns details for each of the incidents in
the list. The request may optionally indicate whether the Web Service should also return
incident violation data and historical information.
For best performance, Symantec recommends that you retrieve multiple incidents in a single
call to the incidentDetails() method. Retrieving 50 – 100 incidents per call provides the
best performance.
The following table describes the IncidentDetailRequest fields.
Table A-2 IncidentDetailRequest fields
DescriptionTypeName
This required field identifies the unique
ID of the Symantec Data Loss
Prevention 12.5.2 or later incident
whose details you want to retrieve.
You may include any number of
incident IDs in the request.
longincidentLongId
This required field identifies the unique
legacy (Symantec Data Loss
Prevention 12.5.1 or previous) ID of
the incident whose details you want to
retrieve. You may include any number
of incident IDs in the request.
intincidentId
38Incident Reporting and Update API Web Service call reference
incidentDetail()
Table A-2 IncidentDetailRequest fields (continued)
DescriptionTypeName
This optional element indicates
whether the Web Service should return
policy violation data with the basic
incident details. A single message may
violate multiple policies, and additional
fields are added to the response for
each policy violation.
Each Symantec Data Loss Prevention
component logs different violation
data. For example, the
NetworkIncidentDetailType
returns a violating header, body, or file
attachment component as part of the
violation data.
See “About incident detail types”
on page 26.
BooleanincludeViolations
This optional element indicates
whether the Web Service should return
incident history information with the
basic incident details.
BooleanincludeHistory
Outputs
Returns an IncidentDetailResponse document. The response includes an
IncidentDetailType object for each incidentId requested. The IncidentDetailType
describes the common features that are shared by all Symantec Data Loss Prevention incidents.
A client may choose to cast the IncidentDetailType to a product group detail type or a
specific product component detail type to access unique features of the incident.
Table A-3 Incident Detail Response
DescriptionTypeName
The incident ID of the requested
incident (Symantec Data Loss
Prevention 12.5.2 or subsequent).
longincidentLongId
39Incident Reporting and Update API Web Service call reference
incidentDetail()
Table A-3 Incident Detail Response (continued)
DescriptionTypeName
The incident ID of the requested
legacy incident (Symantec Data Loss
Prevention 12.5.1 or previous).
If the incident ID exceeds the
maximum integer value, the
IncidentDetailResponse will
return a value of 0 for this field.
intincidentId
The status code returns the status of
the incident detail request. The status
code contains one of the following
values:
■SUCCESS
■AUTHORIZATION_FAILED
■INCIDENT_NOT_FOUND
stringstatusCode
Contains a data structure that returns
the details for the requested incident.
See “About incident detail types”
on page 26.
See “About extended incident detail
types” on page 71.
incidentIncidentDetailType
See “About incident detail types” on page 26.
See “About extended incident detail types” on page 71.
Example
The following example shows how a Java client retrieves the details of a single incident with
incidentDetail().
Note: The Java code in this section is for instructional purposes only and does not demonstrate
a complete client implementation. The sample code is available at the Symantec Support
Center at
http://symantec.com/docs/DOC9265
int incidentId=1;
40Incident Reporting and Update API Web Service call reference
incidentDetail()
boolean includeHistory = true;
boolean includeViolations = true;
IncidentDetailRequest request = new IncidentDetailRequest();
request.getIncidentId().add(incidentId);
request.setIncludeHistory(includeHistory);
request.setIncludeViolations(includeViolations);
try
{
IncidentServicePortType clientPort = client.getPortClient();
IncidentDetailResponse response = clientPort.incidentDetail(request);
for(IncidentDetailResult result: response.getResponse())
{
System.out.println("-------------------------------------------------------");
System.out.println(" Incident details for the incident id: "+ result.getIncidentId());
System.out.println("-------------------------------------------------------\n");
System.out.println("The Response status code is: "+result.getStatusCode());
IncidentDetailType incidentDetails = result.getIncident();
System.out.println("Incident creation date=" + incidentDetails.getIncidentDetectionDate());
}
}
catch (AuthenticationFailedFault ex)
{
System.out.println("User or password is not valid.");
}
catch (AuthorizationFailedFault ex)
{
System.out.println("User is not authorized for this action.");
}
catch (Exception ex)
{
System.out.println(ex.getMessage());
}
Faults
The incidentDetail call return the following general faults:
■ServiceErrorFault
■AuthenticationFailedFault
41Incident Reporting and Update API Web Service call reference
incidentDetail()
■AuthorizationFailedFault
incidentBinaries()
incidentBinaries()— retrieves additional components of the message that generated an
incident, such as the message header, body, and binary attachments.
Syntax
IncidentBinariesResponse =
IncidentServicePortType.incidentBinaries(IncidentBinariesRequest);
Inputs
This call takes a single IncidentBinariesRequest type as its argument.
IncidentBinariesRequest encapsulates the ID of the incident for which to retrieve additional
components. The request can also indicate whether the response document should include
the original message, all message components, or a specific message component in the
response.
Table A-4 IncidentBinariesRequest fields
DescriptionTypeName
This required field identifies the unique
ID of the Symantec Data Loss
Prevention 12.5.2 or later incident
whose components you want to
retrieve.
longincidentLongId
This required field identifies the unique
legacy (Symantec Data Loss
Prevention 12.5.1 or previous) ID of
the incident whose components you
want to retrieve.
If the incident ID exceeds the
maximum integer value, the
IncidentBinariesResponse will
return a value of 0 for this field.
intincidentId
This optional element indicates
whether the Web Service should
include the original message in the
response document.
BooleanincludeOriginalMessage
42Incident Reporting and Update API Web Service call reference
incidentBinaries()
Table A-4 IncidentBinariesRequest fields (continued)
DescriptionTypeName
This optional element indicates
whether the Web Service should
include all message components (for
example, headers and file
attachments) in the response
document.
BooleanincludeAllComponents
This optional element indicates a
specific message component ID to
return in the response document. Each
message component has a unique
component ID. The component long
ID is used in incidents created by
Symantec Data Loss Prevention
12.5.2 or later
longcomponentLongId
This optional element indicates a
specific message component ID to
return in the response document. Each
message component has a unique
component ID. The component integer
ID is used in incidents created by
Symantec Data Loss Prevention
12.5.1 or previous.
If the component ID exceeds the
maximum integer value, the
IncidentBinariesResponse will
return a value of 0 for this field.
intcomponentId
Example
The following example shows how a Java client retrieves a list of incidents with
incidentBinaries().
Note: The Java code in this section is for instructional purposes only and does not demonstrate
a complete client implementation. The sample code is available at the Symantec Support
Center at:
http://symantec.com/docs/DOC9265
int incidentId=1;
boolean getAllComponents=true;
43Incident Reporting and Update API Web Service call reference
incidentBinaries()
int componentId = id;
boolean getOriginalMessage = true;
IncidentBinariesRequest request = new IncidentBinariesRequest();
request.setIncidentId(incidentId);
request.setIncludeAllComponents(getAllComponents);
if(getAllComponents)
{
request.setComponentId(componentId);
}
request.setIncludeOriginalMessage(getOriginalMessage);
request.setIncludeAllComponents(getAllComponents);
try
{
IncidentServicePortType clientPort = client.getPortClient();
IncidentBinariesResponse response = clientPort.incidentBinaries(request);
if(response.getComponent()!=null)
{
for(IncidentBinariesResponse.Component responseComponent : response.getComponent())
{
//downloading all the components including the email body text as an attachment
File file = new File(".");
saveFile(responseComponent.getContent().getInputStream(), file.getCanonicalPath() + \
"\\"+responseComponent.getName());
System.out.println("Binary component Name: "+responseComponent.getName());
System.out.println("Binary component ID: "+responseComponent.getComponentId());
System.out.println("Binary component Type: "+responseComponent.getComponentType());
System.out.println("Saved the binary conent to file: "+ file.getCanonicalPath() + \
"\\"+responseComponent.getName());
}
}
if(Boolean.parseBoolean(getOriginalMessage)
{
File file = new File(".");
saveFile(response.getOriginalMessage().getInputStream(), file.getCanonicalPath() + \
"\\"+"original_message");
System.out.println("Saved the orignal message to: "+ file.getCanonicalPath()+"\\"+ \
"original_message");
}
}
44Incident Reporting and Update API Web Service call reference
incidentBinaries()
catch(Exception exp)
{
System.out.println(exp.getMessage());
exp.printStackTrace();
}
...
private void saveFile(InputStream stream, String fileName) throws IOException
{
// code to write contents of the input stream to a specified file name
}
Faults
The incidentBinaries call can return the following general faults:
■ServiceErrorFault
■AuthenticationFailedFault
■AuthorizationFailedFault
■IncidentNotFoundFault
■ComponentNotFoundFault
■InvalidRequestFault
listCustomAttributes()
listCustomAttributes()—returns a list of all custom attribute names defined in the Symantec
Data Loss Prevention deployment.
Syntax
CustomAttributeList attributeList = servicePort.listCustomAttributes();
Inputs
This method call takes no arguments.
45Incident Reporting and Update API Web Service call reference
listCustomAttributes()
Outputs
Returns a customAttributeList object that contains a list of custom attribute names. You
define custom attributes in the Enforce Server administration console. See "About custom
attributes" in the Symantec Data Loss Prevention Administration Guide.
Examples
Note: The Java code in this section is for instructional purposes only and does not demonstrate
a complete client implementation. The sample code is available at the Symantec Support
Center at:
http://symantec.com/docs/DOC9265
String serviceNamespace ="http://www.company.com/v2011/enforce/webservice/incident";
QName serviceQName = new QName(serviceNamespace,"IncidentService");
URL serviceWsdlUrl = new URl(wsdlLocation);
// The location should be the complete URL starting with https.
// For example: https//enforce_server/ProtectManager/services/v2011/incidents?wsdl
IncidentService webService = new IncidentService(serviceWsdlUrl, serviceQName);
IncidentServicePortType servicePort = webService.getIncidentServicePortType();
CustomAttributeList attributeList = servicePort.listCustomAttributes();
Faults
■AuthenticationFailedFault
■AuthorizationFailedFault
■ServiceErrorFault
listIncidentStatus()
listIncidentStatus()—returns a list of the custom status values defined in the Symantec
Data Loss Prevention deployment.
Syntax
IncidentStatusList statusList = servicePort.listIncidentStatus();
46Incident Reporting and Update API Web Service call reference
listIncidentStatus()
Inputs
The listIncidentStatus() method call takes no arguments.
Outputs
Returns a incidentStatusList object that contains a list of status values. You define status
values in the Enforce Server administration console. See "Configuring status attributes and
values" in the Symantec Data Loss Prevention Administration Guide.
Example
Note: The Java code in this section is for instructional purposes only and does not demonstrate
a complete client implementation. The sample code is available at the Symantec Support
Center at:
http://symantec.com/docs/DOC9265
String serviceNamespace ="http://www.company.com/v2011/enforce/webservice/incident";
QName serviceQName = new QName(serviceNamespace,"IncidentService");
URL serviceWsdlUrl = new URL(wsdlLocation);
// location should be the complete url starting with https
// For example: https//enforce_server/ProtectManager/services/v2011/incidents?wsdl
IncidentService webService = new IncidentService(serviceWsdlUrl, serviceQName);
IncidentServicePortType servicePort = webService.getIncidentServicePortType();
IncidentStatusList statusList = servicePort.listIncidentStatus();
Faults
■AuthenticationFailedFault
■AuthorizationFailedFault
■ServiceErrorFault
updateIncidents()
updateIncidents()—updates incident details for one or more incidents.
47Incident Reporting and Update API Web Service call reference
updateIncidents()
Syntax
IncidentUpdateResponse response = servicePort.updateIncidents(request);
Inputs
Each invocation of the updateIncidents() method defines one or more batches that each
contain a list of one or more incident IDs to be updated. Each batch also defines the fields and
values to update. Only the fields that are specified in the request are updated. To reset the
value of a field, set the new value to a blank string.
Using this batching logic, you can update multiple incidents with the same values. For example,
in a single call to the updateIncidents() method, you can set all of the incidents IDs specified
in the batch to a new status value. You can also specify multiple batches in a single call. Each
batch can specify different incident IDs and values to update.
For best performance, Symantec recommends that you update multiple incidents in a single
batch wherever possible. Updating 50 – 500 incidents per batch provides the best performance.
Incidents are not locked during updates. "Optimistic" locking is used and the most recent
update operation sets the values of the fields. The response to this method call contains a
status message that describes whether or not all the updates succeeded for each batch. An
error is returned when an incident ID is not found.
Table A-5 updateIncidents() instance variables
DescriptionTypeName
The requiredIncidentUpdateBatch field
is available for use by client applications.
You can use this field to track batches of
incident updates. The field is not used by
Symantec Data Loss Prevention. Symantec
recommends that you use a unique identifier
such as a GUID to track batches.
An incident update call can contain multiple
batches that each contain a list of incident
IDs. Each batch also contains a set of
incident fields and values that are to be
updated for all incidents in that batch.
stringbatchID
This required field identifies the unique ID
of the Symantec Data Loss Prevention
12.5.2 or later incident whose details you
want to retrieve. You may include any
number of incident IDs in the request.
longincidentLongId
48Incident Reporting and Update API Web Service call reference
updateIncidents()
Table A-5 updateIncidents() instance variables (continued)
DescriptionTypeName
This required field identifies the unique
legacy (Symantec Data Loss Prevention
12.5.1 or previous) ID of the incident whose
details you want to retrieve. You may
include any number of incident IDs in the
request.
intincidentId
The IncidentAttributes object
represents the set of attributes and values
to be updated for each batch.
See Table A-6.
IncidentAttributesincidentAttributes
Table A-6 IncidentAttributes types and values
DescriptionTypeName
Represents the severity level of the incident.
The possible values are:
■HIGH
■MEDIUM
■LOW
■INFO
The IncidentSeverity field is not case
sensitive.
stringIncidentSeverity
Represents the status value of the incident.
You define incident status values using the
Enforce Server administration console.
See "Configuring status attributes and
values" in the Symantec Data Loss
Prevention Administration Guide.
stringIncidentStatus
Represents notes that are stored with an
incident. You define both the date and the
text of the note.
IncidentNote
■dateAndTime (type: dateTime)
■note (type: string)
IncidentNote
49Incident Reporting and Update API Web Service call reference
updateIncidents()
Table A-6 IncidentAttributes types and values (continued)
DescriptionTypeName
Represents custom attributes that are
associated with an incident. You define zero
or more custom attributes using the Enforce
Server administration console. To update a
specific custom attribute, reference its name
with the name attribute and its value with
the value attribute.
CustomAttributeType
■name (type: string)
■value (type: string)
CustomAttribute
Represents the owner of the data that
caused a policy violation.
DataOwnerType
■name (type: string)
■email (type: string)
DataOwner
50Incident Reporting and Update API Web Service call reference
updateIncidents()
Table A-6 IncidentAttributes types and values (continued)
DescriptionTypeName
Represents the remediation status of an
incident. You can set the following values:
■BLOCKED
■CONTENT_REMOVED
■CUSTOM_ACTION_ON_EMAIL
■EMAIL_APPROVED
■EMAIL_BLOCKED
■EMAIL_MESSAGE_EXPUNGED
■EMAIL_QUARANTINED
■ENDPOINT_BLOCK
■ENDPOINT_NOTIFY
■ENDPOINT_FILE_QUARANTINED
■ENDPOINT_FILE_QUARANTINE_FAILED
■ENDPOINT_NOTIFY_CANCEL_ALLOW
■ENDPOINT_NOTIFY_CANCEL_BLOCK
■ENDPOINT_NOTIFY_CANCEL_TIMEOUT_ALLOW
■ENDPOINT_NOTIFY_CANCEL_TIMEOUT_BLOCK
■FLEX_RESPONSE_ERROR
■FLEX_RESPONSE_EXECUTED
■FLEX_RESPONSE_REQUESTED
■MESSAGE_MODIFIED
■PASSED
■PLACE_HOLDER_DO_NOT_USE
■PROTECT_FILE_COPIED
■PROTECT_FILE_DELETED
■PROTECT_FILE_QUARANTINED
■PROTECT_REMEDIATION_ERROR
■REST_ENCRYTPED
■REST_PERFORMED_DRM
■REST_PERFORMED_BREAK_LINKS
■REST_PERFORMED_CUSTOM_ACTION
stringRemediationStatus
Represents the remediation location of the
incident. Values can be user-defined.
stringRemediationLocation
Outputs
IncidentUpdateBatchResult [batchID,InaccessibleIncidentId,StatusCode]
51Incident Reporting and Update API Web Service call reference
updateIncidents()
Returns an IncidentUpdateResponse object.
The response to this method contains a separate data structure for each batch that was sent
in the request. The data structure contains the fields described in Table A-7.
Table A-7 IncidentUpdateResponse fields
DescriptionTypeName
The batch number that is defined in the update request.stringbatchID
Contains the incident ID of incidents for which an update was
requested but the incident cannot be found.
intInaccessibleIncidentId
The status code indicates the success or failure of the requested
updates of each batch. The possible values are:
■SUCCESS
■PARTIAL SUCCESS
■VALIDATION ERROR
■ALL_INCIDENTS_INACCESSIBLE_OR_DELETED
■AUTHORIZATION_FAILED
■SQL_ERROR
stringstatusCode
Example
Note: The Java code in this section is for instructional purposes only and does not demonstrate
a complete client implementation. The sample code is available at the Symantec Support
Center at:
http://symantec.com/docs/DOC9265
IncidentUpdateRequest request = new IncidentUpdateRequest();
IncidentUpdateBatch batch = new IncidentUpdateBatch();
batch.setBatchId("_" + UUID.randomUUID().toString());
List<IncidentUpdateBatch> actions = request.getUpdateBatch();
actions.add(batch);
List<Integer> incidentIDs = batch.getIncidentId();
incidentIDs.add("IncidentId");
//User provides incident ID
IncidentAttributes attributes = new IncidentAttributes();
batch.setIncidentAttributes(attributes);
52Incident Reporting and Update API Web Service call reference
updateIncidents()
IncidentStatusType status = new IncidentStatusType();
status.setValue("Value");
//User provides the value to be updated
attributes.setStatus(status);
IncidentServicePortType servicePort = client.getPortClient();
IncidentUpdateResponse response = servicePort.updateIncidents(request);
Faults
■AuthenticationFailedFault
■AuthorizationFailedFault
■ServiceErrorFault
incidentViolations()
incidentViolations() returns the highlighted matches for an incident.
Syntax
IncidentViolationsResponse = IncidentServicePortType.
incidentViolations(IncidentViolationsRequest);
Inputs
This call takes a single IncidentViolationsRequest type as its argument.
IncidentViolationsRequest encapsulates the incident ID of the incident.
Table A-8 IncidentViolations instance variable
DescriptionTypeName
This required field identifies the unique
ID of the Symantec Data Loss
Prevention 12.5.2 or later incident
whose violations you want to retrieve.
You may include any number of
incident IDs in the request.
longincidentLongId
53Incident Reporting and Update API Web Service call reference
incidentViolations()
Table A-8 IncidentViolations instance variable (continued)
DescriptionTypeName
This required field identifies the unique
legacy (Symantec Data Loss
Prevention 12.5.1 or previous) ID of
the incident whose violations you want
to retrieve. You may include any
number of incident IDs in the request.
intincidentId
This optional element specifies
whether image violations should be
included in the
IncidentViolationsResponse.
BooleanincludeImageViolations
Output
Returns an IncidentViolationsResponse object that includes all matches in the incident.
Example
Figure A-1 shows an incidentViolationRequest object. The request includes one or more
incident IDs.
Figure A-1 incidentViolationsRequest example
The response object returns a text or file size or document violation.
Figure A-2 shows an incidentViolationResponse object with violating text.
54Incident Reporting and Update API Web Service call reference
incidentViolations()
Figure A-2 incidentViolationsResponse example
The following example shows an incidentViolationResponse object with violating file size:
<ns4:violatingSegment>
<ns4:fileSizeViolation ruleId="1101" ruleName="File Size Rule">
<ns3:violatingFileSize>3310</ns3:violatingFileSize>
<ns3:units>bytes</ns3:units>
</ns4:fileSizeViolation>
</ns4:violatingSegment>
The following example shows an incidentViolationResponse object with violating document
(line breaks added for legibility):
55Incident Reporting and Update API Web Service call reference
incidentViolations()
<ns4:violatingSegment>
<ns4:documentViolation ruleId="1001" ruleName="IDM Rule">
<ns3:documentProfileName>IDM Profile</ns3:documentProfileName>
<ns3:documentPath>C:\Symantec\DataLossPrevention\ServerPlatformCommon\15.5\Protect\
documentprofiles\loremipsum-101\
loremipsum.txt</ns3:documentPath>
<ns3:matchPercentage>100</ns3:matchPercentage>
</ns4:documentViolation>
</ns4:violatingSegment>
56Incident Reporting and Update API Web Service call reference
incidentViolations()
Base Incident Detail Types
This appendix includes the following topics:
■IncidentDetailType
■NetworkIncidentDetailType
■DiscoverIncidentDetailType
■EndpointIncidentDetailType
■RestIncidentDetailType
B
Appendix
IncidentDetailType
IncidentDetailType – defines the common fields that are shared by all Symantec Data Loss
Prevention incidents.
Base fields
IncidentDetailType defines the following fields.
Note that the exact XML fields returned in the IncidentDetailResponse document depend
on the role-based access controls for the Web Service client user. For example, custom attribute
elements are returned only if you explicitly enable that permission for the role to which the
Web Service client belongs.
See “Creating a user and role for an Incident Reporting and Update API client” on page 16.
Table B-1 IncidentDetailType fields
DescriptionOccurrencesTypeField
The incident ID of the requested incident
(Symantec Data Loss Prevention 12.5.2
or subsequent).
1longincidentLongId
The incident ID of the requested legacy
incident (Symantec Data Loss
Prevention 12.5.1 or previous).
If the incident ID exceeds the maximum
integer value, the
IncidentDetailType will return a
value of 0 for this field.
1intincidentId
The date and time when the incident
was added to the Enforce Server
database.
Products such as Endpoint Prevent may
create an incident some time after the
actual violation occurs. This can happen
when endpoints are disconnected from
the network.
1datetimeincidentCreationDate
The date and time at which the
Symantec Data Loss Prevention
software detected the incident.
1datetimedetectionDate
58Base Incident Detail Types
IncidentDetailType
Table B-1 IncidentDetailType fields (continued)
DescriptionOccurrencesTypeField
The severity label of the incident. This
field also contains an integer value
severityId attribute that corresponds
to the severity of the incident.
1IncidentSeverityType
(string)
severity
The status label of the incident. This field
also contains an integer value
statusId attribute that corresponds to
the incident status.
1IncidentStatusType
(string)
status
The localized label that corresponds to
the Symantec Data Loss Prevention
product that generated the incident. This
field also contains a string value
sourceType attribute that indicates the
Symantec Data Loss Prevention product
that generated the incident.
sourceType can be one of:
■NETWORK—Network Monitor,
Network Prevent for Email, or
Network Prevent for Web
■DISCOVER—Network Discover or
Network Protect
■ENDPOINT—Endpoint Discover or
Endpoint Prevent
■DIM
■DAR
1MessageSource (string)messageSource
Contains a string value (and integer
value typeId attribute) that corresponds
to the Symantec Data Loss Prevention
product component that generated the
incident.
Client applications can use the
messageType value to cast the basic
IncidentDetailType into a sub-type
of the product group or product
component that generated the incident.
These sub-types provide additional fields
unique to the group or component.
See “About incident detail types”
on page 26.
1MessageType (string)messageType
59Base Incident Detail Types
IncidentDetailType
Table B-1 IncidentDetailType fields (continued)
DescriptionOccurrencesTypeField
Describes the policy that the message
violated to generate the incident. If a
message violates multiple policies,
additional policies are described in the
otherViolatedPolicy field.
The PolicyType contains a policyId
attribute. This integer attribute uniquely
identifies the policy in the Enforce Server
administration console. PolicyType
also contains a name and version
element to describe the violated policy
further.
1PolicyTypepolicy
Describes the exact rule(s) within the
policy that the message violated. A
single policy can define many rules, and
a given message can potentially violate
each of the policy rules.
The PolicyRuleType contains a ruleId
attribute. This integer attribute uniquely
identifies the policy in the Enforce Server
administration console. PolicyRuleType
also contains the name of the rule in a
ruleName element.
1–manyPolicyRuleTypeviolatedPolicyRule
Describes any additional policies that
the message violated. See the
description of policy above.
0–manyPolicyTypeotherViolatedPolicy
A string value that indicates whether the
message was blocked. This field also
contains an integer value
blockedStatusId attribute that
corresponds to the incident status.
1BlockedStatusType
(string)
blockedStatus
60Base Incident Detail Types
IncidentDetailType
Table B-1 IncidentDetailType fields (continued)
DescriptionOccurrencesTypeField
Indicates the number of detection rule
matches in this incident. The exact
meaning of the matchCount field
depends on the criteria used to detect
the incident. For example, if a policy rule
uses a pattern to detect incidents,
matchCount indicates the number of
pattern matches that were found. If a
rule uses a file type or file size criterion
to detect incidents, the matchCount
value is 1 if the file type or size is
detected.
1intmatchCount
Indicates the number of policy rules that
were violated. This field is included only
when the client requests violation data
with the includeViolations field in
the incidentDetail() request.
0–1intruleViolationCount
The name of the detection server that
created the incident.
1stringdetectionServer
One or more of these elements are
present when custom attributes are
returned in the incident detail.
Custom attributes are optional data
fields that you can use to store
supplemental information about an
incident. Your organization may use
custom attributes to assist in the
workflow for remediating or evaluating
incidents. See the Symantec Data Loss
Prevention Administration Guide for
more information about custom
attributes.
See “Creating a user and role for an
Incident Reporting and Update API
client” on page 16.
0–manyCustomAttributeGroupTypecustomAttributeGroup
61Base Incident Detail Types
IncidentDetailType
Table B-1 IncidentDetailType fields (continued)
DescriptionOccurrencesTypeField
One or more of these elements are
present when you request incident
history to be included in an
incidentDetail call.
The incident history records changes to
the incident status or severity, as well
as any changes enacted by response
rules.
0–manyIncidentHistoryEntryTypeincidentHistory
The dataOwner field includes a
sequence of names and email
addresses that describe the people who
are responsible for remediating this
incident. Each name and email address
must be configured manually, or with a
lookup plug-in. See the Symantec Data
Loss Prevention Administration Guide
for more information.
0-1DataOwnerTypedataOwner
The following table describes the messageType string values and integer ID values associated
with the messageType field. Note that some string values, such as HTTP and FTP, can describe
either a network product category or endpoint product category. Use the typeId attribute value
or examine the messageSource field to determine the exact component type.
Table B-2 messageType integer values
Product component typeProduct category typetypeId
attribute
value
String value
NetworkEmailIncidentDetailNetworkIncidentDetailType2SMTP
NetworkHTTPIncidentDetailNetworkIncidentDetailType3HTTP
NetworkFTPIncidentDetailNetworkIncidentDetailType4FTP
NetworkNNTPIncidentDetailNetworkIncidentDetailType5NNTP
EndpointIMIncidentDetailNetworkIncidentDetailType6MSN
EndpointIMIncidentDetailNetworkIncidentDetailType7AIM
EndpointIMIncidentDetailNetworkIncidentDetailType8YAHOO
62Base Incident Detail Types
IncidentDetailType
Table B-2 messageType integer values (continued)
Product component typeProduct category typetypeId
attribute
value
String value
DiscoverFileSystemIncidentDetailDiscoverIncidentDetailType9Filesystem
NetworkHTTPIncidentDetailNetworkIncidentDetailType10SSL
DiscoverLotusNotesIncidentDetailDiscoverIncidentDetailType11LotusNotes
EndpointLocalFileSystemIncidentDetailEndpointIncidentDetailType13Removable
Storage
EndpointLocalFileSystemIncidentDetailEndpointIncidentDetailType14Local Drive
DiscoverFileSystemScannerIncidentDetailDiscoverIncidentDetailType15EndpointFileSystem
DiscoverWebServerScannerIncidentDetail
The WebServerScanner target was
deprecated in Symantec Data Loss
Prevention 14.5.
DiscoverIncidentDetailType18WebServerScanner
DiscoverFileSystemScannerIncidentDetail
The FileSystemScanner target was
deprecated in Symantec Data Loss
Prevention 14.5.
DiscoverIncidentDetailType19FileSystemScanner
DiscoverLivelinkScannerIncidentDetailDiscoverIncidentDetailType20LiveLinkScanner
DiscoverDocumentumScannerIncidentDetailDiscoverIncidentDetailType21DocumentumScanner
DiscoverGenericScannerIncidentDetailDiscoverIncidentDetailType22GenericScanner
DiscoverWebServiceIncidentDetailDiscoverIncidentDetailType23WebServices
EndpointLocalFileSystemIncidentDetailEndpointIncidentDetailType24CD/DVD
DiscoverSQLDatabaseIncidentDetailDiscoverIncidentDetailType25SQLDatabase
EndpointEmailIncidentDetailEndpointIncidentDetailType26Email/SMTP
EndpointHTTPIncidentDetailEndpointIncidentDetailType27HTTP
EndpointHTTPIncidentDetailEndpointIncidentDetailType28HTTPS/SSL
EndpointFTPIncidentDetailEndpointIncidentDetailType29FTP
EndpointIMIncidentDetailEndpointIncidentDetailType30IM:MSN
63Base Incident Detail Types
IncidentDetailType
Table B-2 messageType integer values (continued)
Product component typeProduct category typetypeId
attribute
value
String value
EndpointIMIncidentDetailEndpointIncidentDetailType31IM:AIM
EndpointIMIncidentDetailEndpointIncidentDetailType32IM:Yahoo
EndpointNetworkIncidentDetailType
Note: This release of Symantec Data Loss
Prevention does not create incidents of this
type.
EndpointIncidentDetailType33Copy to Network
Share
EndpointPrintFaxIncidentDetailEndpointIncidentDetailType34Printer/Fax
EndpointClipboardIncidentDetailEndpointIncidentDetailType35Endpoint clipboard
DiscoverSharePointCrawlerIncidentDetailDiscoverIncidentDetailType36SharePoint
Crawler
This messageType is generated by the Data
Classification for Enterprise Vault solution,
which is licensed separately from Symantec
Data Loss Prevention. There is no product
component type available for this
messageType, and you cannot use the
Incident Reporting and Update API to access
classification results.
n/a37Exchange
DiscoverExchangeCrawlerIncidentDetailDiscoverIncidentDetailType38Exchange crawler
DiscoverBoxCrawlerIncidentDetailDiscoverIncidentDetailType43Box Crawler
EndpointNNTPIncidentDetail is not
implemented in this release.
n/an/an/a
NetworkUniversalIncidentDetailTypeNetworkIncidentDetailType1000 or
greater
Custom protocol
RestDIMIncidentDetailRestIncidentDetailType48REST
Data-in-Motion
(DIM)
RestDARIncidentDetailRestIncidentDetailType49REST Data-at-Rest
(DAR)
64Base Incident Detail Types
IncidentDetailType
NetworkIncidentDetailType
NetworkIncidentDetailType – defines the common properties shared by all incidents in the
Network product group (Network Monitor, Network Prevent for Email, and Network Prevent
for Web).
Base fields
NetworkIncidentDetailType inherits all of the base fields present in IncidentDetailType.
Extension fields
NetworkIncidentDetailType extends IncidentDetailType by adding the following fields:
Table B-3 NetworkIncidentDetailType fields
DescriptionOccurrencesTypeField
The date and time at which the network
message (for example, an email
message, HTTP request, instant
message, or other protocol request) was
created.
1datetimemessageDate
Details about the sender of the network
message, including the sender's IP
address and port number, as well as an
identifying string.
0 - 1NetworkOriginatorTypeoriginator
Details about the intended recipient of
the network message, including the
recipient's IP address and port number,
as well as an identifying string.
0 - manyNetworkRecipientTyperecipient
The full body text of the message that
generated the incident.
0 - 1stringmessageBodyContent
The header text of the original message.
For example, this field includes the
subject header for incidents created by
Network Prevent for Email.
This field is provided only when you
choose to include violation data in the
incident detail request.
0 - 1MessageComponentTypemessageHeader
65Base Incident Detail Types
NetworkIncidentDetailType
Table B-3 NetworkIncidentDetailType fields (continued)
DescriptionOccurrencesTypeField
The partial body text that violated the
policy.
This field is provided only when you
choose to include violation data in the
incident detail request, and only when
violation content appears in the
message body.
0 - 1MessageComponentTypemessageBody
The file that generated the incident. For
example, this field might describe a file
that was transmitted over FTP or a file
attachment to an email message.
This field is provided only when you
choose to include violation data in the
incident detail request.
0 - manyMessageComponentTypefile
66Base Incident Detail Types
NetworkIncidentDetailType
DiscoverIncidentDetailType
DiscoverIncidentDetailType – defines the common properties shared by all Network
Discover/Cloud Storage Discover products.
Base fields
DiscoverIncidentDetailType inherits all of the base fields present in IncidentDetailType.
Extension fields
DiscoverIncidentDetailType extends IncidentDetailType by adding the following fields:
Table B-4 DiscoverIncidentDetailType fields
DescriptionOccurrencesTypeField
The name of the Network
Discover/Cloud Storage Discover Server
that performed the scan.
0 - 1stringtargetServer
The complex type
scanAssignmentType specifies the
date and time that the scan started.
scanAssignmentType also contains
ascanId attribute that specifies the
integer ID of the scan.
1scanAssignmentType
(datetime)
scan
The name of the file share, server, or
SQL database that was scanned.
1stringcontentRootPath
The name of the configured Network
Discover/Cloud Storage Discover target.
0 - 1stringtarget
The URL or file path associated with a
scan target.
0 - 1stringURL
This field indicates whether the incident
was previously detected (Yes or No).
0 - 1stringseenBefore
This field indicates whether the incident
response was superseded by another
response (Yes or No).
1stringsuperseded
The location where the file was copied
or quarantined.
0-1stringremediationLocation
67Base Incident Detail Types
DiscoverIncidentDetailType
EndpointIncidentDetailType
EndpointIncidentDetailType – defines the common properties shared by the Endpoint
Prevent and Endpoint Discover products.
Base fields
EndpointIncidentDetailType inherits all of the base fields present in IncidentDetailType.
Extension fields
EndpointIncidentDetailType extends IncidentDetailType by adding the following fields:
Table B-5
DescriptionOccurrencesTypeField
The date and time at which the violation
occurred. This may be different from the
time at which the actual incident was
created in Symantec Data Loss
Prevention.
1datetimeeventDate
The name of the application that caused
the incident.
0 - 1stringapplicationName
The full path to the application that
caused the incident.
0 - 1stringapplicationPath
The endpoint user name (for example,
MYDOMAIN\bsmith).
0 - 1stringuserName
The computer on which the incident
occurred.
0 - 1stringmachineName
The justification label followed by the
text presented to the end user in the
on-screen notification (for example,
Manager Approved: "My manager
approved the transfer of this data.").
Symantec Data Loss Prevention uses
the label for classification and filtering
purposes in reports.
0 - 1stringuserJustification
This field indicates whether the incident
response was superseded by another
response (Yes or No).
1stringsuperseded
68Base Incident Detail Types
EndpointIncidentDetailType
RestIncidentDetailType
RestIncidentDetailType – defines the common properties that are shared by all Cloud
Connector incidents.
Base fields
RestIncidentDetailType for both DIM (data in motion) and DAR (data at rest) inherits all of
the base fields present in IncidentDetailType.
Extension fields
RestIncidentDetailType extends IncidentDetailType by adding the following attributes:
Note: All attributes are for both DIM and DAR, unless otherwise noted in the Description column.
All attributes are strings.
Table B-6 RestIncidentDetailType fields
DescriptionOccurrencesREST attributeExtension field
Request ID.1common.request.idrequestId
Application name.0-1common.applicationapplicationName
OS of the device.0-1device.osdeviceOS
String value (true or
false) indicating if the
request came from a
trusted device.
0-1device.isTrustedDeviceisTrustedDevice
Cookies from HTTP
requests.
0-1http.cookieshttpCookies
Method for detecting
requests related to
HTTP traffic.
0-1http.methodhttpMethod
URL for detection
requests related to
HTTP traffic.
0-1http.urlhttpUrl
User agent for detection
requests related to
HTTP traffic.
0-1http.userAgenthttpUserAgent
69Base Incident Detail Types
RestIncidentDetailType
Table B-6 RestIncidentDetailType fields (continued)
DescriptionOccurrencesREST attributeExtension field
Geographic location of
the device: latitude.
0-1location.coords.latitudelocationCoordsLatitude
Geographic location of
the device: longitude.
0-1location.coords.longitudelocationCoordsLongitude
Acceptable values:
Download,Upload.
0-1network.directionnetworkDirection
OSI L7 network protocol
applicable to the
detection request:
SMTP, HTTP, FTP, and
so on.
0-1network.protocolnetworkProtocol
A custom context
attribute (Custom
context attributes differ
from the other
well-known context
attributes in their
treatment by the policy
engine.)
0-1customrestCustom
File tag field.0-1common.tagfileTag
Path where the files and
attachments reside.
0-1common.folderfileFolder
String value (true or
false) indicating if the
request came from
inside of the office.
0-1location.isInsideOfficeLocationIsInsideOffice
Describes the risk level
of the target site.
0-1http.siteRiskScorehttpSiteRiskScore
70Base Incident Detail Types
RestIncidentDetailType
Extended Incident Detail
Types
This appendix includes the following topics:
■About extended incident detail types
■Network component detail types
■Discover component detail types
■Endpoint component detail types
■REST component detail types
About extended incident detail types
The following sections provide a reference for the product component incident detail types
included in the Incident Reporting and Update API schema. Component detail types extend
the base product types (NetworkIncidentDetailType,DiscoverIncidentDetailType,
EndpointIncidentDetailType, and RestIncidentDetailType) with fields specific to the
protocol or product component that generated the incident.
See “About incident detail types” on page 26.
Network component detail types
The Incident Reporting and Update API schema defines six component detail types as
extensions to NetworkIncidentDetailType to represent the different protocols that Network
Prevent can monitor. Note that three of the component types add no additional fields, but are
available as placeholders for future extensions.
Table C-1 describes the new fields (if any) added by each network component detail type.
C
Appendix
Table C-1 Network component detail types
DescriptionOccurrencesField typeExtension
field
Component type
NetworkEmailIncidentDetail adds
asubject field to hold the subject of
the email message that generated the
incident.
0-1stringsubjectNetworkEmailIncidentDetail
NetworkHTTPIncidentDetail adds
an HTTPS field to indicate whether the
Web request was transmitted over a
secure connection.
1BooleanHTTPSNetworkHTTPIncidentDetail
This type adds no additional fields to
NetworkIncidentDetailType. It is
provided as a placeholder type for future
extension fields.
n/an/an/aNetworkFTPIncidentDetail
NetworkNNTPIncidentDetail adds
asubject field to hold the subject of
the message that generated the incident.
0-1stringsubjectNetworkNNTPIncidentDetail
This type adds no additional fields to
NetworkIncidentDetailType. It is
provided as a placeholder type for future
extension fields.
n/an/an/aNetworkIMIncidentDetail
NetworkUniversalIncidentDetail
adds a protocolName field to indicate
the custom protocol that was used to
transmit the incident message.
1stringprotocolNameNetworkUniversalIncidentDetail
Discover component detail types
The Incident Reporting and Update API schema defines the following component detail types
as extensions to DiscoverIncidentDetailType:
■DiscoverFileSystemIncidentDetail (Table C-2)
■DiscoverEndpointFileSystemIncidentDetail (Table C-3)
■DiscoverSQLDatabaseIncidentDetail (Table C-4)
■DiscoverLotusNotesIncidentDetail (Table C-5)
■DiscoverGenericScannerIncidentDetail (Table C-6)
72Extended Incident Detail Types
Discover component detail types
■DiscoverFileSystemScannerIncidentDetail (Table C-7)
■DiscoverWebServerScannerIncidentDetail (Table C-8)
■DiscoverLivelinkScannerIncidentDetail (Table C-9)
■DiscoverDocumentumScannerIncidentDetail (Table C-10)
■DiscoverWebServiceIncidentDetail (Table C-11)
■DiscoverSharePointCrawlerIncidentDetail (Table C-12)
■DiscoverExchangeCrawlerIncidentDetail (Table C-13)
■DiscoverBoxCrawlerIncidentDetail(Table C-14)
Each extension type corresponds to the Network Discover/Cloud Storage Discover detection
mechanism that logged the original incident. The tables that follow describe the fields that
each type adds to DiscoverIncidentDetailType.
Table C-2 DiscoverFileSystemIncidentDetail extension fields
DescriptionOccurrencesField typeExtension field
The name of the file that violated the
policy.
1stringfileName
The full path to the file.1stringfilePath
The date and time of the last user
access to the file.
0-1datetimefileLastAccessDate
The date and time when the file was last
changed.
0-1datetimefileLastModifiedDate
The date and time when the file was
created.
0-1datetimefileCreateDate
The owner of the file at the time the
incident was created.
0-1stringfileOwner
73Extended Incident Detail Types
Discover component detail types
Table C-2 DiscoverFileSystemIncidentDetail extension fields (continued)
DescriptionOccurrencesField typeExtension field
The Access Control Lists for the file.
Access Control Lists (ACL) are lists of
the permissions that are attached to an
object or piece of data. The list contains
information about all users who have
read and write permissions for the file.
Use the list to view which users have
access to the file as well as which
actions each user can perform. The
permissions for each user or group are
not set through Symantec Data Loss
Prevention. Administrators set the
permissions for each file using other
applications. Permissions are generally
set at the time that the file is created.
A separate fileACL entry is included
for each permission that was granted on
the file.
fileACL entries are only in certain
Network Discover, Endpoint Discover,
and Endpoint Prevent incidents.
0-manyACLTypefileACL
AmessageComponentType entry that
encapsulates the entire file component.
This field is provided only when you
choose to include violation data in the
incident detail request.
0-manymessageComponentTypefile
Table C-3 DiscoverEndpointFileSystemIncidentDetail extension fields
DescriptionOccurrencesField typeExtension field
The name of the file that violated the
policy.
1stringfileName
The full path to the file.1stringfilePath
The date and time that the file was last
changed.
0-1datetimefileLastModifiedDate
The date and time of the last user
access to the file.
0-1datetimefileLastAccessDate
74Extended Incident Detail Types
Discover component detail types
Table C-3 DiscoverEndpointFileSystemIncidentDetail extension fields (continued)
DescriptionOccurrencesField typeExtension field
The date and time when the file was
created.
0-1datetimefileCreateDate
The owner of the file at the time the
incident was created.
0-1stringfileOwner
The Access Control Lists for the file.
Access Control Lists (ACL) are lists of
the permissions that are attached to an
object or piece of data. The list contains
information about all users who have
read and write permissions for the file.
Use the list to view which users have
access to the file as well as which
actions each user can perform. The
permissions for each user or group are
not set through Symantec Data Loss
Prevention. Administrators set the
permissions for each file using other
applications. Permissions are generally
set at the time that the file is created.
A separate fileACL entry is included
for each permission that was granted on
the file.
fileACL entries are only in certain
Network Discover, Endpoint Discover,
and Endpoint Prevent incidents.
0-manyACLTypefileACL
AmessageComponentType entry that
encapsulates the entire file component.
This field is provided only when you
choose to include violation data in the
incident detail request.
0-manyMessageComponentTypefile
75Extended Incident Detail Types
Discover component detail types
Table C-4 DiscoverSQLDatabaseIncidentDetail extension fields
DescriptionOccurrencesField typeExtension field
Partial body text (extracted from the
database) that violated the policy.
This field is provided under the following
conditions:
■You choose to include violation data
in the incident detail request.
■The violation content appears in the
message body.
0-1MessageComponentTypebody
Full body text of the message that
violated the policy (extracted from the
database).
This field is provided only when you
choose to include violation data in the
incident detail request.
0-1stringbodyContent
Table C-5 DiscoverLotusNotesIncidentDetail extension fields
DescriptionOccurrencesField typeExtension field
The name of the file that violated the
policy.
1stringdocumentName
The name of the user who last changed
the file.
0-1stringlastModifiedBy
The creator of the file.0-1stringcreatedBy
The date and time that the file was last
changed.
0-1datetimelastModifiedDate
The date and time when the file was
created.
0-1datetimecreateDate
Full body text of the message that
violated the policy (extracted from the
database).
This field is provided only when you
choose to include violation data in the
incident detail request.
0-1stringbodyContent
76Extended Incident Detail Types
Discover component detail types
Table C-5 DiscoverLotusNotesIncidentDetail extension fields (continued)
DescriptionOccurrencesField typeExtension field
Body text (extracted from the document)
that violated the policy.
This field is provided only when you
choose to include violation data in the
incident detail request.
0-1messageComponentTypebody
AmessageComponentType entry that
encapsulates the entire file component.
This field is provided only when you
choose to include violation data in the
incident detail request.
0-1messageComponentTypefile
The owner of the file at the time the
incident was created.
0-1stringfileOwner
The full path to the file.1stringfilePath
The Access Control Lists for the file.
Access Control Lists (ACL) are lists of
the permissions that are attached to an
object or piece of data. The list contains
information about all users who have
read and write permissions for the file.
Use the list to view which users have
access to the file as well as which
actions each user can perform. The
permissions for each user or group are
not set through Symantec Data Loss
Prevention. Administrators set the
permissions for each file using other
applications. Permissions are generally
set at the time that the file is created.
A separate fileACL entry is included
for each permission that was granted on
the file.
fileACL entries are only in certain
Network Discover, Endpoint Discover,
and Endpoint Prevent incidents.
0-manyACLTypefileACL
77Extended Incident Detail Types
Discover component detail types
Table C-6 DiscoverGenericScannerIncidentDetail extension fields
DescriptionOccurrencesField typeExtension field
The name of the file that violated the
policy.
1stringfileName
The full path to the file.1stringfilePath
Full body text of the message that
violated the policy (extracted from the
database).
This field is provided only when you
choose to include violation data in the
incident detail request.
0-1stringbodyContent
SQL database metadata that was
generated by Symantec Data Loss
Prevention.
This field is provided only when you
choose to include violation data in the
incident detail request.
0-1messageComponentTypeheader
Body text (extracted from the database)
that violated the policy.
This field is provided only when you
choose to include violation data in the
incident detail request.
0-1messageComponentTypebody
AmessageComponentType entry that
encapsulates the entire file component.
This field is provided only when you
choose to include violation data in the
incident detail request.
0-1messageComponentTypefile
The date and time that the file was last
changed.
0-1datetimefileLastModifiedDate
Table C-7 DiscoverFileSystemScannerIncidentDetail extension fields
DescriptionOccurrencesField typeExtension field
The name of the file that violated the
policy.
1stringfileName
The full path to the file.1stringfilePath
78Extended Incident Detail Types
Discover component detail types
Table C-7 DiscoverFileSystemScannerIncidentDetail extension fields (continued)
DescriptionOccurrencesField typeExtension field
AmessageComponentType entry that
encapsulates the entire file component.
This field is provided only when you
choose to include violation data in the
incident detail request.
0-manymessageComponentTypefile
The date and time when the file was
created.
0-1datetimefileCreateDate
The creator of the file.0-1stringfileCreatedBy
The date and time that the file was last
changed.
0-1datetimefileLastModifiedDate
The date and time of the last user
access to the file.
0-1datetimefileLastAccessDate
The owner of the file at the time the
incident was created.
0-1stringfileOwner
The Access Control Lists for the file.
Access Control Lists (ACL) are lists of
the permissions that are attached to an
object or piece of data. The list contains
information about all users who have
read and write permissions for the file.
Use the list to view which users have
access to the file as well as which
actions each user can perform. The
permissions for each user or group are
not set through Symantec Data Loss
Prevention. Administrators set the
permissions for each file using other
applications. Permissions are generally
set at the time that the file is created.
A separate fileACL entry is included
for each permission that was granted on
the file.
fileACL entries are only in certain
Network Discover, Endpoint Discover,
and Endpoint Prevent incidents.
0-manyACLTypefileACL
79Extended Incident Detail Types
Discover component detail types
Table C-8 DiscoverWebServerScannerIncidentDetail extension fields
DescriptionOccurrencesField typeExtension field
The name of the Web server on which
the scanner detected the incident. This
is the name as configured in the
VontuWebServerScanner.cfg file.
See the Symantec Data Loss Prevention
Administration Guide for more
information about configuring Web
server scans.
1stringname
AmessageComponentType entry that
encapsulates the entire file component.
This field is provided only when you
choose to include violation data in the
incident detail request.
0-manymessageComponentTypefile
The date and time that the file was last
changed.
0-1datetimelastModifiedDate
The full path to the file.1stringfilePath
Table C-9 DiscoverLivelinkScannerIncidentDetail extension fields
DescriptionOccurrencesField typeExtension field
The name of the file that violated the
policy.
1stringfileName
The full path to the file.1stringfilePath
AmessageComponentType entry that
encapsulates the entire file component.
This field is provided only when you
choose to include violation data in the
incident detail request.
0-manymessageComponentTypefile
The date and time when the file was
created.
0-1datetimecreateDate
The date and time that the file was last
changed.
0-1datetimelastModifiedDate
The creator of the file.0-1stringcreatedBy
80Extended Incident Detail Types
Discover component detail types
Table C-9 DiscoverLivelinkScannerIncidentDetail extension fields (continued)
DescriptionOccurrencesField typeExtension field
The name of the user who last changed
the file.
0-1stringlastModifiedBy
The owner of the file.0-1stringfileOwner
Table C-10 DiscoverDocumentumScannerIncidentDetail extension fields
DescriptionOccurrencesField typeExtension field
The name of the file that violated the
policy.
1stringfileName
AmessageComponentType entry that
encapsulates the entire file component.
0-manymessageComponentTypefile
The owner of the file.0-1stringfileOwner
The date and time when the file was
created.
0-1datetimecreateDate
The date and time that the file was last
changed.
0-1datetimelastModifiedDate
The name of the user who last changed
the file.
0-1stringlastModifiedBy
The full path to the file.1stringfilePath
81Extended Incident Detail Types
Discover component detail types
Table C-10 DiscoverDocumentumScannerIncidentDetail extension fields (continued)
DescriptionOccurrencesField typeExtension field
The Access Control Lists for the file.
Access Control Lists (ACL) are lists of
the permissions that are attached to an
object or piece of data. The list contains
information about all users who have
read and write permissions for the file.
Use the list to view which users have
access to the file as well as which
actions each user can perform. The
permissions for each user or group are
not set through Symantec Data Loss
Prevention. Administrators set the
permissions for each file using other
applications. Permissions are generally
set at the time that the file is created.
A separate fileACL entry is included
for each permission that was granted on
the file.
fileACL entries are only in certain
Network Discover, Endpoint Discover,
and Endpoint Prevent incidents.
0-manyACLTypefileACL
Table C-11 DiscoverWebServiceIncidentDetail extension fields
DescriptionOccurrencesField typeExtension field
The name of the file that was sent to the
Web Service.
1stringname
The subject line of the message.
This field is provided only when you
choose to include violation data in the
incident detail request.
0-1MessageComponentTypemessageHeader
The body text of the message.
This field is provided only when you
choose to include violation data in the
incident detail request.
0-1MessageComponentTypemessageBody
82Extended Incident Detail Types
Discover component detail types
Table C-11 DiscoverWebServiceIncidentDetail extension fields (continued)
DescriptionOccurrencesField typeExtension field
This component represents the entire
file that was sent to the Web Service.
This field is provided only when you
choose to include violation data in the
incident detail request.
0-manyMessageComponentTypecomponent
The date and time when the message
was created.
0-1datetimecreateDate
The date and time that the message was
last changed.
0-1datetimelastModifiedDate
The creator of the message.0-1stringcreatedBy
The name of the user who last changed
the file.
0-1stringlastModifiedBy
The owner of the file at the time the
incident was created.
0-1stringfileOwner
The date and time of the last user
access to the file.
0-1datetimefileLastAccessDate
83Extended Incident Detail Types
Discover component detail types
Table C-11 DiscoverWebServiceIncidentDetail extension fields (continued)
DescriptionOccurrencesField typeExtension field
The Access Control Lists for the file.
Access Control Lists (ACL) are lists of
the permissions that are attached to an
object or piece of data. The list contains
information about all users who have
read and write permissions for the file.
Use the list to view which users have
access to the file as well as which
actions each user can perform. The
permissions for each user or group are
not set through Symantec Data Loss
Prevention. Administrators set the
permissions for each file using other
applications. Permissions are generally
set at the time that the file is created.
A separate fileACL entry is included
for each permission that was granted on
the file.
fileACL entries are only in certain
Network Discover, Endpoint Discover,
and Endpoint Prevent incidents.
0-manyACLTypefileACL
Table C-12 DiscoverSharePointCrawlerIncidentDetail extension fields
DescriptionOccurrencesField typeExtension field
The full path to the item.1stringfilePath
The name of the item that violated the
policy.
1stringdocumentName
The date and time when the item was
created.
0-1datetimefileCreateDate
The date and time when the item was
last changed.
0-1datetimefileLastModifiedDate
The creator of the item.0-1stringcreatedBy
The name of the user who last changed
the item.
0-1stringlastModifiedBy
84Extended Incident Detail Types
Discover component detail types
Table C-12 DiscoverSharePointCrawlerIncidentDetail extension fields (continued)
DescriptionOccurrencesField typeExtension field
The body text content of the item in
string format.
This field is provided only when you
choose to include violation data in the
incident detail request.
0-1stringmessageBodyContent
The body text of the item.
This field is provided only when you
choose to include violation data in the
incident detail request.
0-1MessageComponentTypemessageBody
The subject line of the item.
This field is provided only when you
choose to include violation data in the
incident detail request.
0-1MessageComponentTypemessageHeader
AmessageComponentType entry that
encapsulates the entire SharePoint item.
This field is provided only when you
choose to include violation data in the
incident detail request.
0-manymessageComponentTypefile
85Extended Incident Detail Types
Discover component detail types
Table C-12 DiscoverSharePointCrawlerIncidentDetail extension fields (continued)
DescriptionOccurrencesField typeExtension field
The Access Control Lists for the
SharePoint item. Access Control Lists
(ACL) are lists of the permissions that
are attached to an object or piece of
data. The list contains information about
all users who have read and write
permissions for the SharePoint item.
Use the list to view which users have
access to the item as well as which
actions each user can perform. The
permissions for each user or group are
not set through Symantec Data Loss
Prevention. Administrators set the
permissions for each item using
SharePoint. Permissions are generally
set at the time that the item is created.
A separate fileACL entry is included
for each permission that was granted on
the item.
fileACL entries are only in certain
Network Discover, Endpoint Discover,
and Endpoint Prevent incidents.
0-manyACLTypefileACL
Table C-13 DiscoverExchangeCrawlerIncidentDetail extension fields
DescriptionOccurrencesField typeExtension field
The subject line of the item in string
format.
0 - 1stringsubject
Details about the sender of the item,
including the sender's IP address and
port number, as well as an identifying
string.
0 - 1NetworkOriginatorTypeoriginator
Details about the intended recipient of
the item, including the recipient's IP
address and port number, as well as an
identifying string.
0 - manyNetworkRecipientTyperecipient
The full path to the item.1stringfilePath
86Extended Incident Detail Types
Discover component detail types
Table C-13 DiscoverExchangeCrawlerIncidentDetail extension fields (continued)
DescriptionOccurrencesField typeExtension field
The name of the Exchange item (EML
file) that violated the policy.
1stringdocumentName
The date and time when the item was
created.
0-1datetimefileCreateDate
The date and time when the item was
last changed.
0-1datetimefileLastModifiedDate
The creator of the item.0-1stringcreatedBy
The name of the user who last changed
the item. This field may be null if the
Exchange server or connector does not
provide a value.
0-1stringlastModifiedBy
The body text content of the item in
string format.
This field is provided only when you
choose to include violation data in the
incident detail request.
0-1stringmessageBodyContent
The body text of the item.
This field is provided only when you
choose to include violation data in the
incident detail request.
0-1MessageComponentTypemessageBody
For email messages, this corresponds
to the email subject. For other Exchange
items, this field contains a derived
header with metadata about the item.
For example, a contact or appointment
would provide an address or a business
phone as part of the messageHeader.
This field is provided only when you
choose to include violation data in the
incident detail request.
0-1MessageComponentTypemessageHeader
AmessageComponentType entry that
encapsulates the entire Exchange item.
This field is provided only when you
choose to include violation data in the
incident detail request.
0-manymessageComponentTypefile
87Extended Incident Detail Types
Discover component detail types
Table C-14 DiscoverBoxCrawlerIncidentDetail extension fields
DescriptionOccurrencesField typeExtension field
Unique identifier for the file.1stringfileID
The name of the file that violated the
policy.
1stringfileName
sharedLinkInfo is a complex field
type that includes the following
information:
■hasLink: A Boolean value indicating
if the file has a shared link.
■details:
■passwordProtected: A
Boolean value indicating if the
shared link requires a password.
■downloadAllowed: A Boolean
value indicating if the shared link
allows users to download the file.
■expirationDate: A Boolean
value indicating if the shared link
has an expiration date.
1Complex type, see
description.
sharedLinkInfo
The full path to the item.1stringfilePath
The creator of the file.0-1stringfileCreatedBy
The name of the user who last changed
the item.
0-1stringfileModifiedBy
The date and time of the last user
access to the file.
0-1datetimefileLastAccessDate
The date and time when the item was
last changed.
0-1datetimefileLastModifiedDate
The date and time when the item was
created.
0-1datetimefileCreateDate
The owner of the file at the time the
incident was created.
0-1stringfileOwner
88Extended Incident Detail Types
Discover component detail types
Table C-14 DiscoverBoxCrawlerIncidentDetail extension fields (continued)
DescriptionOccurrencesField typeExtension field
fileCollaborator is a complex field
type that includes the following
information:
■collaborator: A string, the name
of any collaborator on the file.
■role: A string, the role of any
collaborator on the file.
0-manyComplex type, see
description.
fileCollaborator
AmessageComponentType entry that
encapsulates the entire Exchange item.
This field is provided only when you
choose to include violation data in the
incident detail request.
0-manymessageComponentTypefile
Endpoint component detail types
Each Endpoint extension type corresponds to the Endpoint detection mechanism that logged
the original incident. The Incident Reporting and Update API schema defines the following
component detail types as extensions to EndpointIncidentDetailType:
■EndpointLocalFileSystemIncidentDetail (Table C-15)
■EndpointPrintFaxIncidentDetail (Table C-16)
■EndpointClipboardIncidentDetail (Table C-17)
■EndpointNetworkIncidentDetailType (Table C-18)
The tables that follow describe the fields that each type adds to EndpointIncidentDetailType.
Several additional detail types are implemented as further extensions to
EndpointNetworkIncidentDetailType:
■EndpointEmailIncidentDetail (Table C-19)
■EndpointHTTPIncidentDetail (Table C-20)
■EndpointIMIncidentDetail
■EndpointFTPIncidentDetail
■EndpointNNTPIncidentDetail
89Extended Incident Detail Types
Endpoint component detail types
EndpointIMIncidentDetail and EndpointFTPIncidentDetail add no additional fields to
EndpointNetworkIncidentDetailType. They are provided as placeholder types for future
extension fields.
EndpointNNTPIncidentDetail is not implemented in this release.
Table C-15 EndpointLocalFileSystemIncidentDetail extension fields
DescriptionOccurrencesField typeExtension field
The name of the file that violated the
policy.
0-1stringfileName
The path to the file.0-1stringfilePath
The volume on which the file is stored.0-1stringvolumeName
The drive letter on which the file is
stored.
0-1stringDOSVolumeName
The timestamp of the last file access.
This information is applicable only to
Endpoint Discover and Endpoint Prevent
local drive monitoring.
0-1datetimefileLastAccessDate
The timestamp when the file was
created. This information is applicable
only to Endpoint Discover and Endpoint
Prevent local drive monitoring.
0-1datetimefileCreateDate
The subject line of the message.
This field is provided only when you
choose to include violation data in the
incident detail request.
0-1MessageComponentTypemessageHeader
The complete file component (the
original file that violated the policy).
This field is provided only when you
choose to include violation data in the
incident detail request.
0-manyMessageComponentTypefile
The file name of the original file when it
is opened and copied to a new
destination.
0-1stringsourceFileName
The file path of the original file when it
is opened and copied to a new
destination.
0-1stringsourceFilePath
90Extended Incident Detail Types
Endpoint component detail types
Table C-16 EndpointPrintFaxIncidentDetail extension fields
DescriptionOccurrencesField typeExtension field
The printer name is available only if the
file cannot be named through from the
printJobTitle, or if the file was
generated from an Internet browser.
0-1stringprinterName
The file name of the printing job that
generated the incident.
0-1stringprintJobTitle
The partial text of the file that violated
the policy.
This field is provided only when you
choose to include violation data in the
incident detail request.
0-1MessageComponentTypecontent
The subject line of the message.
This field is provided only when you
choose to include violation data in the
incident detail request.
0-1MessageComponentTypemessageHeader
Table C-17 EndpointClipboardIncidentDetail extension fields
DescriptionOccurrencesField typeExtension field
The title bar of the window from which
the data was copied.
1stringapplicationWindowTitle
The partial text of the file that violated
the policy.
This field is provided only when you
choose to include violation data in the
incident detail request.
0-1MessageComponentTypecontent
The subject line of the message.
This field is provided only when you
choose to include violation data in the
incident detail request.
0-1MessageComponentTypemessageHeader
91Extended Incident Detail Types
Endpoint component detail types
Table C-18 EndpointNetworkIncidentDetailType extension fields
DescriptionOccurrencesField typeExtension field
The IP address or port of the endpoint
computer that originated the incident.
This is available only if the incident was
created on the endpoint computer.
0-1NetworkOriginatorTypeoriginator
The destination endpoint computer
associated with the incident. This is
available only if the incident was created
on the endpoint computer.
0-manyNetworkRecipientTyperecipient
The subject line of the email/SMTP
message.
This field is provided only when you
choose to include violation data in the
incident detail request.
0-1MessageComponentTypemessageHeader
The body text of the email/SMTP
message.
This field is provided only when you
choose to include violation data in the
incident detail request.
0-1MessageComponentTypemessageBody
The complete file component (the
original file that violated the policy).
This field is provided only when you
choose to include violation data in the
incident detail request.
0-manyMessageComponentTypefile
Table C-19 EndpointEmailIncidentDetail extension fields (extends
EndpointNetworkIncidentDetailType)
DescriptionOccurrencesField typeExtension field
The subject of the email message.
This field is provided only when you
choose to include violation data in the
incident detail request.
0-1stringsubject
92Extended Incident Detail Types
Endpoint component detail types
Table C-20 EndpointHTTPIncidentDetail extension fields (extends
EndpointNetworkIncidentDetailType)
DescriptionOccurrencesField typeExtension field
Indicates whether the Web request was
transmitted over a secure connection.
This field is provided only when you
choose to include violation data in the
incident detail request.
1BooleanisHTTPS
REST component detail types
The Incident Reporting and Update API scheme defines the following component detail types
as extensions toRestIncidentDetailType:
■RestDIMIncidentDetail
■RestDARIncidentDetail
Note: All attributes are for both DIM and DAR, unless otherwise noted in the Description column.
Table C-21 REST component detail types
DescriptionOccurrencesREST attributeExtension field
A site classification such as
"social media."
String type.
0-1http.siteClassificationsiteClassification
A service classification tag
such as "sanctioned" from
Symantec CloudSOC.
String type.
0-1common.service.classificationserviceClassification
A transaction ID that is used
to link back to an incident on
another console.
String type.
0-1common.transactionIdtransactionId
A request ID.
String type.
1common.requestIdrequestId
93Extended Incident Detail Types
REST component detail types
Table C-21 REST component detail types (continued)
DescriptionOccurrencesREST attributeExtension field
The source of the message
used when application
names overlap. For
example: Gatelet, Securlet.
String type.
0-1common.messageSourcemessageSource
The SharePoint site name.
String type.
0-1common.sharepointsharepoint
Whether the device is
compliant based on mobile
device management or
Symantec CloudSOC
information.
Boolean type.
0-1device.isCompliantcompliant
Whether the device is
managed based on mobile
device management or
Symantec CloudSOC
information.
Boolean type.
0-1device.isUnmanagedunmanaged
Whether the device is
personally owned, based on
mobile device management
or Symantec CloudSOC
information.
Boolean type.
0-1device.isPersonalpersonal
The score of the service
used. For example, Box has
a score of 80. From the
Symantec CloudSOC
ShadowIT report.
Integer type.
0-1common.service.scoreserviceScore
94Extended Incident Detail Types
REST component detail types
Table C-21 REST component detail types (continued)
DescriptionOccurrencesREST attributeExtension field
The display name for an
application (such as "Box")
that is not specific to a
Securlet or Gatelet.
String type.
0-1common.application.reportNameapplicationReportName
The DIM or DAR Application
name, such as
securlet.box or
gatelet.box that is
specific to a Securlet or
Gatelet.
String type.
0-1common.applicationapplicationName
For multiple subscriptions.
Not used in 14.6.
String type.
0-1common.application.instanceIdapplicationInstanceId
The authenticated recipient.
When the request is inbound
to a user's device and the
user authentication is known,
it is placed in this field. If
multiple recipients exist,
each recipient is comma
separated; for example,
"Bob, Alice."
String type.
0-1common.authrecipientrecipient
The authenticated sender.
The meaning varies by
detection client. This may be
a logged-on user on an
endpoint, an authenticated
HTTP proxy user, or an
authenticated SMTP user.
0-1common.authsenderauthSender
DAR requests only: File
creation time stamp string
representing the date and
time per ISO 8601, such as
2015-10-13T10:11:06.419Z
0-1common.createdfileCreated
95Extended Incident Detail Types
REST component detail types
Table C-21 REST component detail types (continued)
DescriptionOccurrencesREST attributeExtension field
The type of the data to
process. Consists of one of
three values: *DAR*
(data-at-rest) or *DIM*
(data-in-motion) or *Mobile*
(exclusively for the Secure
Proxy). This value must be
provided with every
detection request.
Fixed dictionary type.
1common.dataTypedataType
The file description field for
DAR requests only.
String type.
0-1common.descriptiondescription
The count of user actions on
the documents.
Long type.
0-1common.doc.activityCountactivityCount
The unique ID of the
document creator.
String type.
0-1common.doc.creatorIdcreatorId
Shows whether the
document has sharing or
access exposures. This field
is set to True if the document
is either publicly shared,
shared with everyone inside
the enterprise or anyone
outside the enterprise. The
field is NOT set to True if the
document is only shared with
specific internal users of the
enterprise.
Boolean type.
0-1common.doc.exposeddocExposed
Shows whether the
document is shared with
everyone inside the
company.
Boolean type.
0-1common.doc.exposures.allInternaldocExposedAllInternal
96Extended Incident Detail Types
REST component detail types
Table C-21 REST component detail types (continued)
DescriptionOccurrencesREST attributeExtension field
The list of email addresses
of people outside the
enterprise that have access
to the document. These are
called external collaborators.
List type.
0-manycommon.doc.exposures.external
.collaborators
docExposuresExternal
Collaborators
List of email addresses of
people inside the enterprise
who have access to the doc.
List type.
0-manycommon.doc.exposures.internal
.collaborators
docExposuresInternal
Collaborators
Shows whether the
document is shared with
everyone publicly. These are
documents that have share
and access permissions
open to anyone on the
internet.
Boolean type.
0-1common.doc.exposures.publicdocExposedPublic
Unique identifier of the
document on the SaaS
application.
String type.
0-1common.doc.iddocumentId
Shows whether the
document is internal to the
enterprise. A document that
is created by a user who
belongs to the enterprise is
termed as an internal
document. Note that creator
of the document is
considered.
Boolean type.
0-1common.doc.isInternaldocInternal
Unique ID of the parent
folder.
String type.
0-1common.doc.parentFolderIdparentFolderIdentifier
97Extended Incident Detail Types
REST component detail types
Table C-21 REST component detail types (continued)
DescriptionOccurrencesREST attributeExtension field
The type of document.
Possible values are file, File,
folder, Folder. Also, the type
of the primary object to
which the activity applies: for
example, Account, Site, File,
or Folder.
String type.
0-1common.doc.typedocumentType
The path where the files or
attachments reside.
String type.
0-1common.folderfileFolder
DAR requests only. Last
accessed time stamp. The
string representing date and
time is per ISO 8601. For
example:
2015-10-13T10:11:06.419Z
0-1common.lastAccessedlastAccessed
DAR requests only. Last
modified time stamp. The
string representing date and
time is per ISO 8601. For
example:
2015-10-13T10:11:06.419Z
0-1common.lastModifiedlastModified
The unique identifier for the
log (use for deep linking).
String type.
0-1common.log.idlogId
DAR requests only. The user
ID of the owner of the file or
attachment.
String type.
0-1common.ownerowner
DAR requests only. The
array of user IDs the
document is shared with.
List type.
0-manycommon.sharedWithsharedWith
98Extended Incident Detail Types
REST component detail types
Table C-21 REST component detail types (continued)
DescriptionOccurrencesREST attributeExtension field
DAR requests only. The URL
used to share the document.
String type.
0-1common.sharingUrlsharingUrl
DAR requests only. The file
tag field.
String type.
0-1common.tagfileTag
The threat score associated
with the user or event.
Long type.
0-1common.user.threatScorethreatScore
Indicates whether the user
is internal or external to the
enterprise.
Boolean type.
0-1common.user.isInternaluserInternal
The number of documents
exposed to a user.
Long type.
0-1common.user.docsExposedCountdocExposedCount
The list of groups that the
user belongs on the SaaS
application.
Long type.
0-manycommon.user.groupMembershipgroupMembership
The unique ID for the user.
String type.
0-1common.user.iduserId
The display name.
String type.
0-1common.user.nameuserName
The type of action that is
performed on the primary
object; for example: "Allow"
or "Add" or “Create” or
“Delete”.
String type.
0-1common.user.activityTypeuserActivityType
99Extended Incident Detail Types
REST component detail types
Table C-21 REST component detail types (continued)
DescriptionOccurrencesREST attributeExtension field
A custom context attribute.
Custom context attributes
differ from the other well
known context attributes in
their treatment by the policy
engine.
0-1customrestCustom
The Boolean value (true or
false) indicating if the
request came from a trusted
device.
Boolean type.
0-1device.isTrustedDevicedevicesIsTrusted
The operating system of the
device as a string value.
String type.
0-1device.osdeviceOS
The type of the device as
string value.
String type.
0-1device.typedeviceType
The name of the browser, as
derived from user agent.
String type.
0-1http.browserhttpBrowser
The cookies from HTTP
requests.
String type.
0-1http.cookieshttpCookies
The method for detection
requests related to HTTP
traffic.
String type.
0-1http.methodhttpMethod
The risk level of the target
site, as a numeric value.
Long type.
0-1http.siteRiskScorehttpSiteRiskScore
100Extended Incident Detail Types
REST component detail types
Table C-21 REST component detail types (continued)
DescriptionOccurrencesREST attributeExtension field
The URL for detection
requests related to HTTP
traffic.
String type.
0-1http.urlhttpUrl
The user agent for detection
requests related to HTTP
traffic.
String type.
0-1http.userAgenthttpUserAgent
The link to the Symantec
CloudSOC console
exposures panel for that
document.
String type.
0-1link.doc.exposurelinkDocExposure
The link to the incident in the
Symantec CloudSOC
console.
String type.
0-1link.incidentlinkIncident
The link to the Symantec
CloudSOC Service Visibility
UI with the panel for that
user.
String type.
0-1link.service.applicationlinkServiceApplication
Launches the Symantec
CloudSOC console to the
Investigate UI with a list of
the last 7 days of activity for
that user. Filtered by the
application and the
username.
String type.
0-1link.ubalinkUba
101Extended Incident Detail Types
REST component detail types
Table C-21 REST component detail types (continued)
DescriptionOccurrencesREST attributeExtension field
The link to the Symantec
CloudSOC console
Securlets UI with a list of the
exposures panel for that
user.
String type.
0-1link.user.exposureslinkDocExposure
The geographic location of
the device in latitude.
String type.
0-1location.coords.latitudelocationCoordsLatitude
The geographic location of
the device in longitude.
0-1location.coords.longitudelocationCoordsLongitude
The Boolean value (true or
false) indicating if the
request came from inside the
office.
0-1location.isInsideOfficeinsideOfficeLocation
The recorded location of
where the activity was
performed. Format: City
(Country).
String type.
0-1location.regionlocationRegion
The recorded country where
the activity was performed.
String type.
0-1location.region.countryregionCountry
Indicates if this DIM call is
for content upload or
download. The acceptable
values are download and
upload.
Fixed dictionary type.
0-1network.directionnetworkDirection
The OSI L7 network protocol
applicable to the detection
request. For example:
"SMTP," "HTTP," or "FTP."
String type.
0-1network.protocolnetworkProtocol
102Extended Incident Detail Types
REST component detail types
Table C-21 REST component detail types (continued)
DescriptionOccurrencesREST attributeExtension field
The network recipient IP
applicable to the detection
request.
String type.
0-1network.recipient.ipnetworkRecipientIp
The network recipient port
applicable to the detection
request.
Long type.
0-1network.recipient.portnetworkRecipientPort
The network sender IP
address applicable to the
detection request.
String type.
0-1network.sender.ipnetworkSenderIp
The network sender port
applicable to the detection
request.
Long type.
0-1network.sender.portnetworkSenderPort
103Extended Incident Detail Types
REST component detail types
A
activityCount field 96
AIM incidents 64
AOL Instant Messenger incidents 64
API 17
applicationInstanceId field 95
applicationName field 68–69, 95
applicationPath field 68
applicationReportName field 95
applicationWindowTitle field 91
attributes 17, 61
AuthenticationFailedFault 46–47, 53
authenticationFailedFault 31, 37, 41, 45
understanding 22
authenticaton
certificate 21
AuthorizationFailedFault 46–47, 53
authorizationFailedFault 37, 42, 45
authSender field 95
B
batchID 48
binary data 42
blockedStatus field 60
body field 76–78
bodyContent field 76, 78
Box crawler 64
C
CD incidents 63
certificate authentication 21
certificates 22
clients
authenticating 22
generating code for 21
implementing 14
troubleshooting 31
clipboard incidents 64
Cloud Connector 69
compliant field 94
component field 83
componentId field 43
componentNotFoundFault 45
components. See product components
content field 91
contentRootPath 67
createDate field 76, 80–81, 83
createdBy field 76, 80, 83–84, 87
creatorId field 96
credentials 13, 22–23
custom attributes 18, 25, 61
custom protocols 64
CustomAttribute 50
customAttributeGroup field 61
customAttributeList 46
D
DataOwner 50
dataOwner field 62
dataType field 96
description field 96
detectionDate field 58
detectionServer field 61
development frameworks 11, 21
development systems 15
deviceIsTrusted field 100
deviceOS field 69, 100
deviceType field 100
Discover. See Network Discover/Cloud Storage
Discover
DISCOVER group 59
DiscoverBoxCrawlerIncidentDetail type 64, 89
DiscoverBoxCrawlerIncidentDetailType 26
DiscoverDocumentumScannerIncidentDetail type 63,
82
DiscoverEndpointFileSystemIncidentDetail type 75
DiscoverExchangeCrawlerIncidentDetail type 64, 87
DiscoverFileSystemIncidentDetail type 63, 74
DiscoverFileSystemScannerIncidentDetail type 63,
79
DiscoverGenericScannerIncidentDetail type 63, 78
Index
DiscoverIncidentDetailType 26, 67
DiscoverLivelinkScannerIncidentDetail type 63, 81
DiscoverLotusNotesIncidentDetail type 63, 77
DiscoverSharePointCrawlerIncidentDetail type 64, 86
DiscoverSQLDatabaseIncidentDetail type 63, 76
DiscoverWebServerScannerIncidentDetail type 63,
80
DiscoverWebServiceIncidentDetail type 63, 84
display attributes 17
docExposed field 96
docExposedAllInternal field 96
docExposedCount 99
docExposedPublic field 97
docExposuresExternalCollaborators field 97
docExposuresInternalCollaborators field 97
docInternal field 97
documentId field 97
documentName field 76, 84, 87
documentType field 98
Documentum scanner 63
DOSVolumeName field 90
DVD incidents 63
E
email incidents 63, 92–93
encryption 11
endpoint components 89
Endpoint Discover 26, 59, 90
ENDPOINT group 59
Endpoint Prevent 26, 59, 90
EndpointClipboardIncidentDetail type 64, 91
EndpointEmailIncidentDetail 92
EndpointEmailIncidentDetail type 63
EndpointFileSystem 63
EndpointFTPIncidentDetail 89
EndpointFTPIncidentDetail type 63
EndpointHTTPIncidentDetail 93
EndpointHTTPIncidentDetail type 63
EndpointIMIncidentDetail 89
EndpointIMIncidentDetail type 62–64
EndpointIncidentDetailType 26, 68
EndpointLocalFileSystemIncidentDetail type 63, 90
EndpointNetworkIncidentDetailType 92
EndpointNetworkIncidentDetailType type 64
EndpointNNTPIncidentDetail 89
EndpointNNTPIncidentDetail type 64
EndpointPrintFaxIncidentDetail type 64, 91
eventDate field 68
Exchange crawler 64
extended incident detail types 71
extension fields 65, 67–69, 74–82, 84, 86–87, 89–93,
103
F
faults 37
fax incidents 64
file field 66, 74–75, 77–81, 85, 87, 89–90, 92
file fields 74–75, 78–82, 86–87
fileACL field 74–75, 77, 79, 82, 84, 86
fileCollaborator field 89
fileCreated field 95
fileCreateDate field 73, 75, 79, 84, 87–88, 90
fileCreatedBy field 79, 88
fileFolder field 70, 98
fileID field 88
fileLastAccessDate field 73–74, 79, 83, 88, 90
fileLastModified field 73–74
fileLastModifiedDate field 78–79, 84, 87–88
fileModifiedBy field 88
fileName field 73–74, 78, 80–81, 88, 90
fileOwner field 73, 75, 77, 79, 81, 83, 88
filePath field 73–74, 77–78, 80–81, 84, 86, 88, 90
filesystem scanner 63
fileTag field 70, 99
filters 20
frameworks 21
FTP incidents 63
G
groupMembership 99
H
header field 78
header text 65
history data 39
HTTP basic authentication 11, 22–23
HTTP incidents 63
httpBrowser field 100
httpCookies field 69, 100
httpMethod field 69, 100
HTTPS 11
HTTPS field 72
HTTPS incidents 63
httpSiteRiskScore field 70, 100
httpUrl field 69, 101
httpUserAgent field 69, 101
105Index
I
IDs 13, 19, 35
Incident Reporting and Update API 7
See also about
See also Web service
components of 9
creating role for 16
creating user for 16
generating client code for 9, 21
implementing client of 14
localizing 11
privileges 17
requirements for using 10, 12
schema for 10
security for 11
troubleshooting 31
WSDL 9
Incident Reporting and Update API role 16
Incident Reporting privilege 17
Incident Update privilege 17
incidentapi-2011-schema.jar file 10
incidentAttributes 49
incidentBinaries() requests 25, 42
troubleshooting 45
IncidentBinariesRequest object 42
incidentCreationDate field 58
incidentCreationDateLaterThan 36
incidentDetail() 37
incidentDetail() requests 25
troubleshooting 41
IncidentDetailRequest object 38
IncidentDetailResponse object 39
IncidentDetailType 26, 39, 58
incidentHistory field 62
incidentId field 38, 42, 49, 54, 58
incidentList() requests 25, 34
troubleshooting 37
IncidentListResponse object 36
incidentLongId field 38, 42, 48, 53, 58
IncidentNote 49
incidentNotFoundFault 31, 45
incidents 8, 19, 35
binary data of 25
custom attributes 25
details of 25
listing 13, 25
status 25
types of 26, 71
updating attributes 25
IncidentSeverity 49
IncidentStatus 49
incidentStatusList 47
includeAllComponents field 43
includeHistory 39
includeImageViolations field 54
includeOriginalMessage field 42
includeViolations field 39
insideOfficeLocation field 102
instant messenger incidents 64
intrusion detection systems 8
invalidRequestFault 45
IP addresses 92
isHTTPS field 93
istTrustedDevice field 69
J
Java 8, 10
authenticating with 23
retrieving incident binary data with 43
retrieving incident details with 40
JAX-WS code 21
justifications 68
L
lastAccessed field 98
lastModified field 98
lastModifiedBy field 76, 81, 83–84, 87
lastModifiedDate field 76, 80–81, 83
lifecycle events 32
linkDocExposure field 101–102
linkIncident field 101
linkServiceApplication field 101
linkUba field 101
listCustomAttributes() 25, 45
listIncidentStatus 46
listIncidentStatus() 25
LiveLink scanner 63
local drive incidents 63
localhost.log file 33
locationCoordsLatitude field 70, 102
locationCoordsLongitude field 70, 102
LocationIsInsideOffice field 70
locationRegion field 102
log files 31
logId field 98
Lotus Notes incidents 63
106Index
M
machineName field 68
Manager.Logging.properties file 32
manager_operational.log file 32
matchCount field 61
message components 43
messageBody field 66, 82, 85, 87, 92
messageBodyContent field 65, 85, 87
messageDate field 65
messageHeader field 65, 82, 85, 87, 90–92
messageSource field 27, 59, 94
messageType field 30, 59
values of 64
Metro Web Services 11
Microsoft .NET 10, 21–22
authenticting with 23
MSN incidents 63
N
name field 80, 82
.NET. See Microsoft .NET
network components 71
Network Discover 26, 67
Network Discover/Cloud Storage Discover 59
component types for 72
NETWORK group 59
Network Monitor 26, 59, 65
Network Prevent for Email 26, 59, 65
Network Prevent for Web 26, 59, 65
Network Protect 26, 59
networkDirection field 70
networkDirection filed 102
NetworkEmailIncidentDetail type 62, 72
NetworkFTPIncidentDetail type 62
NetworkHTTPIncidentDetail type 62–63, 72
NetworkIncidentDetailType 26, 65, 72
NetworkNNTPIncidentDetail type 62, 72
networkProtocol field 70
networkProtocol firld 102
networkRecipientIp field 103
networkRecipientPort field 103
networkSenderIp field 103
networkSenderPort field 103
NetworkUniversalIncidentDetail 72
NetworkUniversalIncidentDetailType 64
O
operational log files 32
original message text 42
originator field 65, 86, 92
otherViolatedPolicy field 60
owner field 98
P
parentFolderIdentifier field 97
personal field 94
policies 60
policy field 60
printer incidents 64
printerName field 91
printJobTitle field 91
product components 13, 30, 59, 64, 71–72, 89
product groups 26, 59, 64
production servers 16
proxy class
.NET 21
proxy classes 10
proxy code 21
R
recipient field 65, 86, 92, 95
recipients 65, 86
regionCountry field 102
RemediationLocation 51
remediationLocation field 67
RemediationStatus 51
removable storage incidents 63
Reporting API. See Incident Reporting and Update
API
Reporting API privileges 17
reports. See saved reports
requestId field 69, 93
REST detail types 103
restCustom field 70, 100
RestDARIncidentDetailType 64
RestDIMIncidentDetailType 64
RestIncidentDetailType 69
role-based access privileges 18, 58
roles 16
rules 60
ruleViolationCount field 61
S
saved reports 13, 19
savedReportId field 35
scan 67
107Index
scanAssignmentType 67
scanner incidents 63
scans 67
schema 10
seenBefore 67
senders 65, 86
serviceClassification field 93
ServiceErrorFault 46–47, 53
serviceErrorFault 37, 41, 45
serviceScore field 94
severity field 59
sharedLinkInfo field 88
sharedWith field 98
SharePoint crawler 64
sharepoint field 94
sharingUrl field 99
Simple Object Access Protocol. See SOAP
single-tier installations 15
siteClassification field 93
SMTP incidents 63, 92–93
SOAP 8, 13
troubleshooting 32
SQL database incidents 63
SSL 11, 21–22
SSL incidents 63
status
incidents 25
status field 59
subject field 72, 86, 92
superseded 67–68
system events 32
T
target 67
targets 67
targetServer 67
threatScore field 99
Tomcat
logging errors with 33
transactionId field 93
typeId attribute 62
U
unmanaged field 94
updateIncidents 47
updateIncidents() 25
URL 21, 67
URLs 67
user privileges 17
userActivityType field 99
userId field 99
userInternal field 99
userJustification field 68
userName field 68, 99
users 16
V
violatedPolicyRule field 60
violation data 39
volumeName field 90
W
Web Server scanner 63
Web Service 24
See also Incident Reporting and Update API
authenticating 11
authenticating client with 22
binding 22
generating client code for 21
implementing client of 14
incidents for 63
permission requirements for using 13
supported operations for 24
troubleshooting 32
Web Services 17
Web Services Description Language. See WSDL
webservice_access.log file 32
webservices_soap.log file 32
WSDL 8–9, 21
consuming 21
wsimport utility 21–22
X
XML schemas 30
XSD files 10
Y
Yahoo! IM incidents 64
108Index

Navigation menu