eset_protect: add HTTP header identifying the integration

[eset-enterprise-integration]

Proposed commit message

eset_protect: add HTTP header identifying the integration

The ESET Protect API will be requiring an HTTP header, "3rd-integration", to
identify integrations. Documentation for the header is not currently
available, but will be at the ESET Elastic integration documentation page[1]
in the future.

[1]https://help.eset.com/eset_connect/en-US/elastic.html

Checklist

• [x] I have reviewed tips for building integrations and this pull request is aligned with them.
• [x] I have verified that all data streams collect metrics or logs.
• [x] I have added an entry to my package's changelog.yml file.
• [x] I have verified that Kibana version constraints are current according to guidelines.
• [x] I have verified that any added dashboard complies with Kibana's Dashboard good practices

How to test this PR locally

We will see changes in our monitoring after release

Related issues

No issue

[cla-checker-service[bot]]

💚 CLA has been signed

[elasticmachine]

Pinging @elastic/security-service-integrations (Team:Security-Service Integrations)

[eset-enterprise-integration]

I have signed CLA

[eset-enterprise-integration]

Is there an issue that explains why this is happening?

Please add a proposed commit message to the PR description explaining what is being done and why.

The manifest.yml will need a change in the version field to match the entry in the changelog.

[efd6]

/test

[efd6]

Is there documentation for this in the API docs?

[eset-enterprise-integration]

Is there documentation for this in the API docs?

not yet, we will add it after release

[efd6]

Ideally, this should go in the commit message.

[eset-enterprise-integration]

/test we will see changes in our monitoring after release

[elastic-vault-github-plugin-prod[bot]]

:rocket: Benchmarks report

Package eset_protect :+1:(1) :green_heart:(0) :broken_heart:(2)

Expand to view

Data stream | Previous EPS | New EPS | Diff (%) | Result ----------- | ------------ | ------- | -------- | ------ `detection` | 1919.39 | 1501.5 | -417.89 (-21.77%) | :broken_heart: `event` | 1996.01 | 1675.04 | -320.97 (-16.08%) | :broken_heart:

To see the full report comment with /test benchmark fullreport

[elastic-sonarqube[bot]]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[elasticmachine]

:green_heart: Build Succeeded

• Buildkite Build
• Commit: e514651bb055259589797dcfe16c26c61f0c9196

[efd6]

Sorry, let me clarify: the link to documentation should go in the commit message. If it cannot, I will rewrite the commit message to explain that. This is less than ideal though.

[eset-enterprise-integration]

I add link to commit message. But information about header will be there later. Thanks

[efd6]

Thanks. Out of curiosity, is there a reason for not using RFC 7231 5.5.3 for this? This is well within what that was designed for.

[elastic-vault-github-plugin-prod[bot]]

Package eset_protect - 1.2.0 containing this change is available at https://epr.elastic.co/package/eset_protect/1.2.0/

[eset-enterprise-integration]

Thanks. Out of curiosity, is there a reason for not using RFC 7231 5.5.3 for this? This is well within what that was designed for.

We didn't know this