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

[EBT] Apply PII filters to the events #132259

Open
Tracked by #121992
afharo opened this issue May 16, 2022 · 3 comments
Open
Tracked by #121992

[EBT] Apply PII filters to the events #132259

afharo opened this issue May 16, 2022 · 3 comments
Labels
Feature:Telemetry Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc

Comments

@afharo
Copy link
Member

afharo commented May 16, 2022

Our developers are very conscious about the data that we send and care about not sending any PII.

Especially, since we need to declare the schemas, it provides us with an additional read-proof understanding of the data to identify these cases. On top of that, whenever we identify a leak, we can remotely disable the offending event type.

However, this system is far from perfect and we should implement a piece of logic to apply some schema-agnostic PII filtering.

We may choose to implement this on the receiving end to avoid any performance overload on the Kibana end. However, the sooner we apply the filters, the better for the end-user. Also, if implemented on the client-side, we'll prove that we care about PII because it'll show redacted in the audit logs #132256

@botelastic botelastic bot added the needs-team Issues missing a team label label May 16, 2022
@afharo afharo changed the title Implement event-processing to apply PII filters (client and/or remote) to redact any potential PII information. Ideally, it should be schema-agnostic. [EBT] Apply PII filters to the events May 16, 2022
@afharo afharo added Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc Feature:Telemetry labels May 16, 2022
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-core (Team:Core)

@botelastic botelastic bot removed the needs-team Issues missing a team label label May 16, 2022
@pgayvallet
Copy link
Contributor

pgayvallet commented May 18, 2022

What exact filtering mechanism are we thinking about here?

Usually, sensible data filtering is done by redacting a predetermined subset of a list of fields or data structures, e.g

const FORBIDDEN_HEADERS = ['authorization', 'cookie', 'set-cookie'];
const REDACTED_HEADER_TEXT = '[REDACTED]';

Given that, for our EBT events, the source of each event is fully in control of the event's 'owner', such per-field filtering does not make sense, given we already know precisely which fields are going to be sent, doesn't it?

So I'm assuming we're talking about value-based and not key-based filtering here? In that case, which data are we thinking of trying to identify as being sensible, and more importantly, how?

@afharo
Copy link
Member Author

afharo commented May 18, 2022

So I'm assuming we're talking about value-based and not key-based filtering here?

Your assumption is correct! I tried to claim this intent in schema-agnostic PII filtering in the description 😇

In that case, which data are we thinking of trying to identify as being sensible, and more importantly, how?

I guess that's to be defined? Probably the @elastic/platform-analytics and @pauldotpower can help out with the list.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Telemetry Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc
Projects
None yet
Development

No branches or pull requests

3 participants