ServiceNow

<div class="condensed-table">
| | |
| --- | --- |
| Version | 0.9.0 [beta] (View all) |
| Compatible Kibana version(s) | 8.16.2 or higher |
| Supported Serverless project types
What’s this? | Security
Observability |
| Subscription level
What’s this? | Basic |
| Level of support
What’s this? | Elastic |

</div>

ServiceNow is a cloud-based platform that helps organizations improve their workflows and business processes, mainly in IT service management. It offers features like workflow automation, a self-service portal for users, integration with other systems, and helpful reporting tools.

ServiceNow uses tables to store data, making it easy to manage and retrieve information. A key part of the platform is the Configuration Management Database (CMDB), which keeps track of IT assets and how they are connected.

The ServiceNow integration can be used in three different modes to collect logs:

• AWS S3 polling mode: ServiceNow writes data to S3, and Elastic Agent polls the S3 bucket by listing its contents and reading new files. Refer to the ServiceNow documentation for how to integrate AWS S3 with ServiceNow for retrieving logs into an S3 bucket.
• AWS S3 SQS mode: ServiceNow writes data to S3; S3 sends a notification of a new object to SQS; the Elastic Agent receives the notification from SQS and then reads the S3 object. Multiple agents can be used in this mode.
• REST API mode: ServiceNow offers table APIs to retrieve data from its tables; the Elastic Agent polls these APIs to list their contents and read any new data. Visit this page for additional information about REST APIs.

This module has been tested with the latest(updated as of August 1, 2024) version of Xanadu on ServiceNow.

The ServiceNow integration supports both custom tables and the default tables offered by ServiceNow. Additionally, both types of tables are included in the data stream labeled event.

Below is a list of the default ones.

• alm_hardware
• change_request
• change_task
• cmdb
• cmdb_ci
• cmdb_ci_app_server
• cmdb_ci_appl
• cmdb_ci_business_app
• cmdb_ci_computer
• cmdb_ci_db_instance
• cmdb_ci_esx_server
• cmdb_ci_hardware
• cmdb_ci_hyper_v_server
• cmdb_ci_infra_service
• cmdb_ci_linux_server
• cmdb_ci_server
• cmdb_ci_service
• cmdb_ci_vm
• cmdb_ci_win_server
• cmdb_rel_ci
• cmn_department
• cmn_location
• incident
• kb_knowledge
• problem
• sc_req_item
• sys_user
• sys_user_grmember
• sys_user_group
• task_ci

NOTE:

1. This integration currently supports ECS mapping for default ServiceNow tables listed above. For custom tables created by users, ECS mapping is not automatically provided. If you want to add mappings for custom tables, please refer to this tutorial guide.
2. A tag will be added to each table based on its name. For example, if logs are ingested from the alm_hardware table, users can view them in Discover by using the query tags: "alm_hardware".

• Elastic Agent must be installed.
• You can install only one Elastic Agent per host.
• Elastic Agent is required to stream data through the REST API or AWS S3/SQS and ship the data to Elastic, where the events will then be processed via the integration’s ingest pipelines.

You have a few options for installing and managing an Elastic Agent:

With this approach, you install Elastic Agent and use Fleet in Kibana to define, configure, and manage your agents in a central location. We recommend using Fleet management because it makes the management and upgrade of your agents considerably easier.

With this approach, you install Elastic Agent and manually configure the agent locally on the system where it’s installed. You are responsible for managing and upgrading the agents. This approach is reserved for advanced users only.

You can run Elastic Agent inside a container, either with Fleet Server or standalone. Docker images for all versions of Elastic Agent are available from the Elastic Docker registry, and we provide deployment manifests for running on Kubernetes.

There are some minimum requirements for running Elastic Agent. For more information, refer to the Elastic Agent installation guide.

• Your instance URL will serve as your base URL and will be formatted as follows: https://<instance_id>.service-now.com
• Additionally, the username and password you use to log into your instance will be required to fetch logs in our integration.

• With an AWS S3 bucket that has been set up, you can configure it with ServiceNow by integrating it using your AWS S3 credentials.

1. Assuming you’ve already set up a connection to push data into the AWS bucket you can follow the steps below; if not, see the section above.

2. To set up an SQS queue, follow "Step 1: Create an Amazon SQS Queue" as described in the Amazon S3 user guide.

   • While creating an access policy, use the bucket name configured to create a connection for AWS S3 in ServiceNow.

3. Configure event notifications for an S3 bucket according to the Amazon S3 user guide.

   • While creating event notification select the event type as s3:ObjectCreated:*, destination type SQS Queue, and select the queue name created in Step 2.

• In the Data Collection section, use the Time Zone Offset field to set your preferred timezone. The .value field for date data will always be in UTC, while the .display_value field can reflect your instance’s selected timezone. The system default is set to America/Los_Angeles, but you can change this in your ServiceNow profile settings.

• Steps to See/Update the timezone in ServiceNow Instance:

  1. Click the user icon in the top-right corner of the ServiceNow interface.
  2. Select Profile from the dropdown menu.
  3. In your Profile settings, locate the Timezone option.

1. In Kibana go to Management > Integrations.

2. In "Search for integrations" search bar, type ServiceNow.

3. Click on the "ServiceNow" integration from the search results.

4. Click on the "Add ServiceNow" button to add the integration.

5. While adding the integration, if you want to collect logs via REST API, then you have to put the following details:

   • collect logs via REST API toggled on

   • API URL

   • username

   • password

   • table name

   • timestamp field

   • timezone offset

     or if you want to collect logs via AWS S3, then you have to put the following details:

   • collect logs via S3 Bucket toggled on

   • access key id

   • secret access key

   • bucket arn

   • table name

   • timestamp field

   • timezone offset

     or if you want to collect logs via AWS SQS, then you have to put the following details:

   • collect logs via S3 Bucket toggled off

   • access key id

   • secret access key

   • queue url

   • table name

   • timestamp field

   • timezone offset

6. Click on "Save and Continue" to save the integration.

• By default, the integration expects the data in S3 to match with ServiceNow REST API, i.e., each field as an object containing a .value and .display_value keys with their corresponding values. For more examples on sample events format, see here.
• If users are unable to store such key-value pairs of .value and .display_value inside S3 buckets, and the fields inside S3 buckets are scalars containing only Display Values of the fields, users can choose to enable the integration option Data Has Only Display Values under Advanced options. Instead, if the S3 buckets contain scalar fields with Values from each fields, users can disable this option. By default, the option is disabled.
• When the option Data Has Only Display Values is enabled, the ingest pipeline converts each scalar field to object by adding .display_value. For example, if this option is enabled, the S3 data "install_status":"Installed" is converted to "install_status":{"display_value":"Installed"} by the ingest pipeline. When this option is disabled, a similar S3 scalar form "install_status":"Installed" is converted to "install_status":{"value":"Installed"} by the ingest pipeline.
• This ensures proper parsing of ingest pipeline without causing mapping conflicts or processor failures.

This is the Event dataset.

{
    "@timestamp": "2024-09-24T05:39:40.000Z",
    "agent": {
        "ephemeral_id": "121d1e8c-0c94-4812-a446-4e8c339cbf5e",
        "id": "744b1c23-395c-4123-9b8a-7e975ed7b1f8",
        "name": "docker-fleet-agent",
        "type": "filebeat",
        "version": "8.14.0"
    },
    "data_stream": {
        "dataset": "servicenow.event",
        "namespace": "28538",
        "type": "logs"
    },
    "ecs": {
        "version": "8.11.0"
    },
    "elastic_agent": {
        "id": "744b1c23-395c-4123-9b8a-7e975ed7b1f8",
        "snapshot": false,
        "version": "8.14.0"
    },
    "event": {
        "agent_id_status": "verified",
        "category": [
            "configuration",
            "threat"
        ],
        "created": "2016-12-12T15:19:57.000Z",
        "dataset": "servicenow.event",
        "id": "1c741bd70b2322007518478d83673af3",
        "ingested": "2024-12-02T12:33:55Z",
        "kind": "event",
        "severity": 3,
        "timezone": "America/Los_Angeles",
        "type": [
            "info"
        ]
    },
    "input": {
        "type": "cel"
    },
    "related": {
        "user": [
            "David Loo",
            "Joe Employee",
            "employee",
            "admin"
        ]
    },
    "servicenow": {
        "event": {
            "activity_due": {
                "display_value": "2016-12-12T17:26:36.000-08:00",
                "value": "2016-12-13T01:26:36.000Z"
            },
            "assigned_to": {
                "display_value": "David Loo",
                "value": "5137153cc611227c000bbd1bd8cd2007"
            },
            "closed_at": {
                "display_value": "2016-12-13T18:46:44.000-08:00",
                "value": "2016-12-14T02:46:44.000Z"
            },
            "opened_at": {
                "display_value": "2016-12-12T07:19:57.000-08:00",
                "value": "2016-12-12T15:19:57.000Z"
            },
            "opened_by": {
                "value": "681ccaf9c0a8016400b98a06818d57c7"
            },
            "priority": {
                "display_value": "3 - Moderate",
                "value": 3
            },
            "severity": {
                "display_value": "3 - Low"
            },
            "state": {
                "display_value": "Closed",
                "value": "7"
            },
            "sys_created_by": {
                "display_value": "employee",
                "value": "employee"
            },
            "sys_created_on": {
                "display_value": "2016-12-12T07:19:57.000-08:00"
            },
            "sys_domain": {
                "display_value": "global",
                "value": "global"
            },
            "sys_domain_path": {
                "display_value": "/",
                "value": "/"
            },
            "sys_id": {
                "value": "1c741bd70b2322007518478d83673af3"
            },
            "sys_updated_by": {
                "display_value": "admin",
                "value": "admin"
            },
            "sys_updated_on": {
                "display_value": "2024-09-23T22:39:40.000-07:00",
                "value": "2024-09-24T05:39:40.000Z"
            },
            "table_name": "incident"
        }
    },
    "tags": [
        "incident",
        "hide_sensitive",
        "forwarded",
        "servicenow-event"
    ],
    "user": {
        "name": "Joe Employee"
    }
}