Tenable.sc Integration with ServiceNow - MID Server system requirements

Maloy Banerjee1
Tera Expert

‎11-10-2023 07:40 AM

Hi All,

 

I have to integrate Tenable.sc with ServiceNow and have a couple of queries with regard to the MID Server.

  1. Can we use the existing MID Server? or Do I need to install a dedicated MID Server? What does the best practice say?
  2. If we are using an existing MID Server, what are the changes needed in the existing MID Server? Do we need to only configure the ports? or are there some more settings needed?
  3. If I am using a dedicated MID Server, what is the system and memory size required for the MID Server? In my case, approximately 90000 CIs are going to be scanned for vulnerabilities.
  4. How many MID Servers are needed?
  5. I have got the below diagram from ServiceNow documentation, but there is no explanation. Can someone explain the whole diagram? What is happening in the highlighted area of the box? What do the VM1 tool and VM2 tool mean? (I guess VM1 means Tenable but what is VM2?)

 

MaloyBanerjee1_0-1699630533080.png

 

 

Regards,

Maloy Banerjee

0 Helpfuls
  • 1,024 Views
1 REPLY 1

andy_ojha
ServiceNow Employee
ServiceNow Employee

‎11-14-2023 09:03 AM - edited ‎11-14-2023 09:08 AM

Hey there,

 

That diagram should be reviewed with some context -- i.e. with the title "Conceptual", the idea was to illustrate that different vulnerability scanners can be integrated a few different ways - some need a MID Server and some do not...

1) Vulnerability Tools hosted in the cloud, may already be ingesting vuln data from on-prem gear 
    - No need to use a MID Server, as ServiceNow will just talk to the service / API in the cloud 
    - E.g. Tenable.IO, Qualys Cloud

2) Vulnerability Tools hosted on-prem, behind a firewall
    - Will need to use a MID Server, to allow ServiceNow (Cloud) to talk to gear on-prem (the vuln scanner mgmt host)
    - E.g. Tenable.SC on-prem behind a firewall

 

-----------------------------------------------------------

There are no specific sizing guides or minimum requirements for MID Server specs / builds, specific to SecOps VR.

 

The environmental requirements you mentioned are key (ensure there is appropriate routing in place, network connectivity for the MID to talk to the vuln mgmt console - e.g. Tenable.SC)... if a firewall is in-between then that needs to be sorted out, etc.

 

You may also want to plan for SSL Certificate challenges - if the on-prem gear is not employing a trusted SSL Cert or is using a self-signed SSL cert, the MID Server may have issues establishing connectivity.

If you are able to use a standalone MID Server for your Production ServiceNow Instance and environment, that is a good first start.

  • This way - you minimize the risk of interrupting another process area by sharing their MID Server, and you also minimize impacting SecOps VR due to an issue stemming from another process on that MID Server 
  • You can follow the standard MID Server sizing guidance that is published today 
  • https://docs.servicenow.com/bundle/vancouver-servicenow-platform/page/product/mid-server/reference/r...
  • The MID Server is not doing any actual processing of the data - it is really just acting as a broker to request the data, store the file, transfer the file -- containing the real VR payload data -- the ServiceNow instance itself then takes that file and does the heavy lifting 

Where sizing will come into play, is on the actual ServiceNow Instance(s) themselves - depending on the volume of data we will ingest, the ServiceNow instance should be reviewed to determine if it sized to handle the processing and data storage needs.   This requires a special request that you can work with NOW Support on (Instance Sizing Assessment with Vulnerability Response data)...

 

For Sub-Production instance(s)

  • You could look at getting another standalone MID Server - or perhaps if that is not possible, share a MID Server that others are already using 
  • If you can get a separate MID Server for sub-prod
    • You can connect different Sub-production ServiceNow instance(s) to it - i.e. install a different MID Agent for DEV, TEST, STAGE, etc. onto it 
    • No real need to have a different server / host for each sub-prod ServiceNow instance
0 Helpfuls