Push or Pull in an integration? How are you handling?

[Suggy]

Hey all,

Need your help or advice on this situation. There is an external tool which has Computer data. That tool has got inbuilt discovery capabilities..

Now the requirement is to have that data loaded into ServiceNow CMDB tables on a daily basis.

We told them we ll share our import set API/scripted rest API and asked them to push it.

But they are denying that asking us only to do the GET/PULL operation.

As we all know, 

- If its a push from external tool, developer from their side needs to do some development. So both we and they need to work.

- If its a PULL from ServiceNow, we need to do all the developments and NO work from their side at all.

So question is - In general, how are you handling this PUSH vs PULL scenarios when it comes to such data loading?

Which of the above approaches we need to go with? Any pros and cons of either of the above methods?

[Suggy]

Hi @Danish Bhairag2 

When you say 

"### PULL Approach:

2. **Security:** The external tool does not need to expose APIs, potentially enhancing security."

What exactly you meant above? If we want to pull the data from SErviceNow via web service, we need to use the GET web service method for which they NEED to expose their APIs right?

[Danish Bhairag2]

Hi @Suggy ,

Here's a breakdown of what it means:

1. **Reduced Attack Surface:** When an external tool doesn't expose APIs, it reduces the attack surface because there are fewer entry points for potential malicious activities. APIs, if not properly secured, could be vulnerable to attacks like unauthorized access, injection attacks, etc.

2. **Minimized Exposure:** Exposing APIs means making certain endpoints accessible over the network. In a PULL scenario, the external tool can be kept behind firewalls or other security measures, limiting its exposure to the external environment.

3. **Simplified Access Control:** With a PULL approach, access control can be more tightly managed by controlling access to the ServiceNow instance, which is initiating the data retrieval. This can be beneficial in scenarios where the external tool is considered more sensitive or prone to security risks.

4. **Easier Compliance:** Depending on regulatory or compliance requirements, not exposing APIs might simplify the adherence to certain security standards. This is because exposing APIs often involves additional considerations for securing those endpoints.

However, it's important to note that security considerations are multifaceted, and the decision to expose or not expose APIs depends on the specific security requirements, the nature of the data being transferred, and the overall architecture of the integration. Each approach (PUSH or PULL) has its own security implications, and organizations should carefully assess their specific security needs when making integration decisions.

Thanks,

Danish

[rvandolson]

Are you (or anyone else reading) actually restricting access to your SNOW instance by IP address?  AFAIK, there's no way to do this for the API space only, rather you need to do it for everything.

With "work from anywhere" still being quite popular, and potential integration sources for SNOW living in AWS or other places with massive IP address spaces, limiting access at the Layer 3 level seems daunting.

Curious how some of you with large deployments manage this in the real world.

[Aly Ahmed]

the best approach for SNOW is to get them to PUSH to SNOW as this will minimize snow development work and also future maintenance like if the other system have upgrades or changes.

However this might delay your project as you become dependent on there efforts and if they have a developer/desire to do the work 

the other option to GET/PULL, SNOW will have full control of development and control in when data will come to you and also avoid/manage performance pitfalls if the load is big  

[Dr Atul G- LNG]

it's NOT SNOW.. It's SN or ServiceNow