Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhance the existing CSP violation reporting pipeline to include more fields and support other policy violation reports #175113

Closed
5 tasks done
azasypkin opened this issue Jan 18, 2024 · 2 comments
Assignees
Labels
Feature:Security/CSP Platform Security - Content Security Policy Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more!

Comments

@azasypkin
Copy link
Member

azasypkin commented Jan 18, 2024

Summary

In the scope of #162974 and #153584, we successfully adapted the event-based telemetry (EBT) framework for the collection of CSP violation reports. Now that we know it works well for this use case, we can consider moving further and enhancing this reporting pipeline to cover other types of policy violation reports (e.g., Permission Policy violation reports). Additionally, we need to add more fields to the violation reports to make monitoring and investigation more efficient, so that the final document/report might look like this:

{
  // Common fields
  "type": "csp-violation" | "permissions-policy-violation",
  "timestamp": number,
  "url": string,
  "user_agent": string,
  "disposition": "enforce" | "report",
  "sourceFile": string,
  "lineNumber": number,
  "columnNumber": number,
  "version/kibanaVersion/service.version": string (but `version` data type), 
  "orgId"?: string, <-- NEW (if possible)
  "deploymentId"?: string,
  "serverless.projectId"?: string,
  "hasCustomPlugins": boolean, <-- NEW (if possible, TBD)

  // CSP violation-specific fields
  "blockedURL": string,
  "referrer": string,
  "documentURL": string,
  "effectiveDirective": string,
  "originalPolicy": string,
  "statusCode": number,

  // Permission policy violation-specific fields
  "featureId": string, 
}

In addition to new fields, we also need to add the ingest pipeline with the following processors to make data more filterable/searchable:

  • User agent processor to parse the user_agent field, so that we have dedicated fields for the user agent's OS and browser, which might be beneficial while debugging OS- or browser-specific issues.

Tasks

  • Work with the Kibana Core team to figure out if it's possible to detect whether Kibana has any custom plugins enabled or not (required by hasCustomPlugins report field)
  • Update Kibana code to capture new fields that don't exist yet in the violation reports (version, deploymentId, etc.)
  • Rename all telemetry indexing jobs, EDN files, and other related telemetry-specific files for _all environments to reflect that the pipeline is no longer CSP-specific (e.g. kibana-security-csp-violations.edn --> kibana-security-web-policy-violations.edn)
  • Update telemetry EDN file to include all new and existing fields that weren't indexed before
  • Work with the analytics/telemetry team to add ingest pipelines/ingest processors for violation reports data (e.g., user agent processor)
@azasypkin azasypkin added Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! Feature:Security/CSP Platform Security - Content Security Policy labels Jan 18, 2024
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-security (Team:Security)

@elena-shostak elena-shostak self-assigned this Jun 21, 2024
elena-shostak added a commit that referenced this issue Jul 4, 2024
## Summary

1. Added top-level `permissionsPolicy` configuration setting.
2. Added support for `report_to` directive.
3. Added support for `Permissions-Policy-Report-Only` header to enable
reporting mode.
4. The [spec](https://www.w3.org/TR/permissions-policy/#reporting)
mentions `featureId` in the reporting body, however the field is
`policyId` in Chromium.

## How to test

- Add in your `kibana.dev.yml`.
```
server.customResponseHeaders.Reporting-Endpoints: violations-endpoint="https://localhost:5601/kibana/internal/security/analytics/_record_violations"
server.securityResponseHeaders.permissionsPolicy: 'microphone=()'
server.securityResponseHeaders.permissionsPolicyReportOnly: 'camera=()'
```
- Make sure you have [dev tools configured for Reporting
API](https://developer.chrome.com/docs/capabilities/web-apis/reporting-api#use_devtools).
- In the browser console invoke `navigator.mediaDevices.getUserMedia({
audio: true, video: true }).catch((e) => {});`
- Open Dev Tools -> Application -> Reporting API. 
You should see 2 reports for permissions violation, one with `report`
disposition and another with `enforce` disposition.

<img width="1285" alt="Screenshot 2024-06-27 at 13 36 12"
src="https://github.com/elastic/kibana/assets/165678770/3f3da7f6-f6b0-4f33-9a81-dff3db0ac2b8">


### Checklist

- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [x] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)

### For maintainers

- [ ] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)

### Related Issue(s)
#175113,
#184939

### Release Note
Added support for Permissions Policy reporting.
@legrego
Copy link
Member

legrego commented Aug 5, 2024

All work here is done!

@legrego legrego closed this as completed Aug 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Security/CSP Platform Security - Content Security Policy Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more!
Projects
None yet
Development

No branches or pull requests

4 participants