HEC / Webhook / Signed Event Webhook, OAuth

[wellsjp]

We use HEC to ingest data from multiple sources but are starting to see the requirement for OAuth and other security features on webhooks.  Does anyone know if it is on the roadmap to support this?  Our current example is using a webhook from sendgrid.

https://www.twilio.com/docs/sendgrid/for-developers/tracking-events/event

[PickleRick]

I'm sorry but I fail to understand how authenticating the sending side to the HEC receiver or signing the requests is supposed to protect the confidentiality of PII.

The thing here would be to verify the identity of the receiver (most probably using TLS mechnisms) and use encryption for the transport channel.

OAuth is (can be) used for authenticating the sender and signing is (can be) used for integrity/non-repudiation.

So what problem are you trying to solve?

[david_keough]

Same org as OP, different role.

SendGrid - at this time only has webhook integration that uses OAUTH2 or Cryptographic Signaling with no ability to access header configuration to use the Splunk HTTP Event Collector tokens.

The Token CAN be embedded in the URL target itself but might be able to be intercepted enroute before encrypted handshakes.  If this happens another actor could potentially impersonate and flood the HEC with garbage data.  Admittedly the attack surface is small and the damage is mostly ingestion and headache.

It has less to do with PII protection and more so the non-repudiation factor in this case.

If other Cloud based SaaS applications go this route then ingestion data from these will require cribl or some other other solution to serve as a receiver/validator before forwarding.

[PickleRick]

Well, as I'm reading the specs for those webhooks it seems there are two different mechanisms at play here.

One is OAuth which seems a bit silly here since webhooks are supposed to be fast, easy to implement, robust and so on. OAuth seem overly complicated for a simple webhook but let's leave it at this point. OAuth solves the case of authentication - it lets the client say hello properly to the server so that the server can decide whether to authorize the client to use the service (post the webhook) or not. This has nothing to do with non-repudiation.

And is indeed more or less the equivalent of the HEC token.

The non-repudiation part is indeed performed with event signatures but it's kinda orthogonal thing to Splunk. Splunk is not a general "webhook processing solution". Splunk's HEC is meant to receive events. Just that.

I'd say that the way to go would be to put something "in front" of Splunk to capture both the webhook contents as well as the signature and either validate the signature or send both the contents and the signature to Splunk (and have a way to later verify said signature).

[isoutamo]

If I recall right there have been discussions about oauth2 with Splunk’s future releases. Maybe you could found something from participating voc.splunk.com?

But oauth2 is targeting to authenticate and authorize into splunk searches, not for ingesting data via hec or other ways. Maybe there will be some modular inputs in future which will be use it! But currently e.g. HEC will be using only token based authentication only.

[livehybrid]

Hi @wellsjp 

I personally havent seen anything on a roadmap for this - I would recommend submitting an idea at https://ideas.splunk.com/ - once you've done that let us know the link/Ref and I will upvote it too!

🌟 Did this answer help you? If so, please consider:

• Adding karma to show it was useful
• Marking it as the solution if it resolved your issue
• Commenting if you need any clarification

Your feedback encourages the volunteers in this community to continue contributing