-
Notifications
You must be signed in to change notification settings - Fork 584
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
Information Classification Extension #785
Changes from all commits
e9335fa
0625461
a29625f
b8bab86
edf6aa8
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,48 @@ | ||
# Information Classification | ||
|
||
As part of ISO27001 control objective A8.2 aims to address 'Information | ||
Classification' whereby information and data in an organization is properly | ||
managed, including classification in relation to sensitivity of the data, | ||
legislation etc. A.8.2.2 requires that electronic assets be 'labeled', | ||
and this extension allows the `data` of cloudevents to be appropriately labeled | ||
with the `classification` of the event being shared. | ||
|
||
Organizations will typically have their own internal Information Management | ||
policies and standards that might address these control objectives differently, | ||
however this extension provides a consistent framework for labeling | ||
events, where an organization can use their own internal values for | ||
`classification`. | ||
|
||
This extension is not opinionated on how this classification will be used and | ||
does not, for example, imply different encryption schemes etc. | ||
|
||
For Sainsburys-tech colleagues, additional information can be found on our | ||
internal confluence under `/display/IC/Information+Classification+Extension`, | ||
which, for example, includes the values from our own classification policies. | ||
|
||
## Attributes | ||
|
||
### classification | ||
|
||
- Type: `String` | ||
- Description: The `classification` of the `data`. The value SHOULD be expressed | ||
in uppercase. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why put a constraint on the uppercase part, I think the classification labels should be open? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. |
||
- Constraints: | ||
- REQUIRED | ||
- MUST be a non-empty string (TBD) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. what's the TBD for? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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". |
||
|
||
# Examples | ||
|
||
The following example shows a CloudEvent the producer has labeled as PUBLIC: | ||
|
||
```JSON | ||
{ | ||
"specversion" : "1.0", | ||
"type" : "com.github.pull_request.opened", | ||
"source" : "https://github.com/cloudevents/spec/pull/123", | ||
"id" : "A234-1234-1234", | ||
"datacontenttype" : "text/xml", | ||
"classification" : "PUBLIC", | ||
"data" : "<much wow=\"xml\"/>", | ||
} | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be useful to allow multiple values
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.