Information Classification Extension

[matthunt1984]

This is the first draft of a data classification extension to cloud events.

I've created this PR as draft to allow debate from JS colleagues or others in the community.

[duglin]

can you make ISO027001 a link to the spec?

[matthunt1984]

Unfortunately this one of those specs you need to buy, which is why I didn't link directly... on our internal intranet I linked to some non-normative articles where people have discussed these reference

I can maybe:
Link to wiki https://en.wikipedia.org/wiki/ISO/IEC_27001
Copy the link that wiki reference to the spec https://www.bsigroup.com/en-GB/about-bsi/media-centre/press-releases/2005/11/ISOIEC-27001-International-Information-Security-Standard-published/

I think Wikipedia might be better, if we were to link to anything?

[JemDay]

Hey @matthunt1984 ..

• Looks like you need to sign-off your recent commit.
• I'm curious as to how you see this being used, I understand the need for such data classification internally but i'm not clear on how this would be used on a per-event-basis. Is this type of meta-data better represented as a part of the event data schema and/or exposed via discovery APIs.

[JemDay]

I also still struggle with en-US; I'm waiting for somebody to comment on your commit comment s/Americanised/Americanized ;-)

[duglin]

what's the TBD for?

[matthunt1984]

I guess I wanted a second opinion on this. My starting point would be to not allow an empty string, unless it had a specific purpose. You could for example theoretically have a component that implements the extension, but didn't know how to classify the data after inspection. In such a state you could use "" or maybe an explicit "Unknown".
I think the better implementation is that the field be omitted which maintains the data is 'unclassified' and therefore I'd suggest "MUST be a non-empty string"

[loopingz]

Why put a constraint on the uppercase part, I think the classification labels should be open?

[matthunt1984]

I wasn't sure here, I figured it was better to assume case-insensitivity as "public" and "PUBLIC" for example should be treated equally to avoid potential confusions. It's also common practice in a few organizations I've been in to use uppercase on documents as it makes it clear the word is used as a 'keyword, in relation to policy'. Perhaps we could define the values should be treated case-insensitive, but allow the value set either way? I was leaning to force upper as it makes it explicit, and the 'SHOULD' allows flexibility if for some reason it were problematic.

[loopingz]

It might be useful to allow multiple values

[matthunt1984]

Interesting, I'm not sure the underlying standard supports multiple labels. It's normally a hierarchy and you would therefore label with the most sensitive label. This might be worth validating with someone who knows the underlying spec better.

[tweing]

We had the exact same discussions in our company. Classification is a very broad concept and it is difficult to apply to the whole payload of the event. We also had discussions on how a consumer would use this attribute and we did not came to a common conclusion. It would be more beneficial to know, which attributes of the payload are privacy relevant. On the other hand it might be handled differently around the Globe. It is a difficult topic though.

Long story short, we ended up providing a generic boolean value for privacyrelevant to indicate the consumer that they should be careful in processing in terms of privacy or not.

Additionally we added a generic labels array with key/value pairs for someone who sees a need for classification or any other type of information seen useful.

We are still in a learning phase whether these attributes make sense or not. Therefore we did not propose them as extensions to CloudEvents yet.

[matthunt1984]

• I'm curious as to how you see this being used, I understand the need for such data classification internally but i'm not clear on how this would be used on a per-event-basis. Is this type of meta-data better represented as a part of the event data schema and/or exposed via discovery APIs.
  @JemDay

We had the exact same discussions in our company. Classification is a very broad concept and it is difficult to apply to the whole payload of the event. We also had discussions on how a consumer would use this attribute and we did not came to a common conclusion. It would be more beneficial to know, which attributes of the payload are privacy relevant. On the other hand it might be handled differently around the Globe. It is a difficult topic though.

Long story short, we ended up providing a generic boolean value for privacyrelevant to indicate the consumer that they should be careful in processing in terms of privacy or not.

Additionally we added a generic labels array with key/value pairs for someone who sees a need for classification or any other type of information seen useful.

We are still in a learning phase whether these attributes make sense or not. Therefore we did not propose them as extensions to CloudEvents yet.
@tweing

I think these are some key debate points as to whether this extension gets put into practice. Here is where I'm personally a fan of field-level classification on a schema, or where that might not be possible to try and do so at interface-level (i.e. every message in may cases, would have the same classification). However my wider org is also interested in the event-level approach, so I said that I'd show how this would look if we did it as an extension, and it was the first extension use case that had support.

For reference, I did a POC on Avro using field-level schema with certain fields tagged as Personally Identifiable Information (PII). This is for me the ideal approach for our use case : https://github.com/matthunt1984/avro-generic-anonymiser

[duglin]

@matthunt1984 any update on this?

[duglin]

tap tap tap... @matthunt1984 you still interested in this?

[matthunt1984]

I've not had much support in my org and I'm still personally in favour of alternatives, so suggest we can close?