Consider adding a field for "informasjonsklasse"

[mortenwh]

B3: "Som informasjonssikkerhetsleder så ønsker jeg å vite dataenes informasjonsklasse.

Jeg ønsker å sikre at vi bruker egnet lagringsplattform og tilgangsstyring til riktig informasjonsklasse og at dette reflekteres i dataenes metadata-beskrivelser.

Slik at vi holder oss innenfor lovverket og minsker risikoen for å få konfidensielle (skjermet) data på avveie."

This will require a controlled vocabulary.

[steingod]

Do we have the controlled vocabulary to use?

[mortenwh]

Yes, from METCIM:

• Åpen

  • Dette er standardklassen for informasjon i MET. Informasjon som kan deles internt og eksternt, så sant ikke dokumentet er unntatt offentlighet jf. offentleglova
  • Eksempler
    • åpne data jf METs datapolitikk
    • åpne kildekode jf METs datapolitikk
    • presseskriv, markedsføringsmateriell, åpne rapporter
    • offentlig tilgjengelig kontaktinformasjon -annen åpen og offentlig informasjon fra MET

• Intern

  • Intern virksomhetsinformasjon som ikke skal deles med personer utenfor MET.
  • Eksempler:
    • intern virksomhetsinformasjon; Blest, Personalhåndboka, METCIM, arkitektur-, system-, drifts-, og brukerdokumentasjon, retningslinjer, prosess/prosedyrebeskrivelser, e-post til interne mottakere.

• Skjermet

  • Informasjon som er skjermet med hjemmel i offentleglova (Unntatt offentlighet)
  • Informasjon tilhørende denne klassen skal være tydelig merket og det skal være tydelig angitt hvem som er informasjonseier.
  • Eksempler:
    • passord og andre hemmeligheter
    • forretningshemmeligheter som ikke offentliggjorte strategier, anskaffelsesdokumenter og kommersielle kontrakter
    • detaljerte ROS-analyser, avvik og beredskapsplaner
    • særlige kategorier personopplysninger og personopplysninger i avvik og logger som kan være belastende for enkeltindivider
    • detaljert arkitektur og systemdokumentasjon (som viser potensielle sårbarheter)
    • prosjektsøknader (forskning)
    • dokumentasjon/data rundt leveranser til Forsvaret

• Gradert

  • Informasjon som er skjermet med hjemmel i beskyttelsesinstruksen og offentleglova
    • Graderinger:
      • FORTROLIG
      • STRENGT FORTROLIG
    • Eksempler
      • Informasjon som ikke kan graderes etter sikkerhetsloven men det kan skade offentlige interesser, en bedrift, en institusjon eller en enkeltperson at dokumentets innhold blir kjent for uvedkommende
  • Informasjon som er gradert med hjemmel i sikkerhetsloven
    • Graderinger
      • BEGRENSET KONFIDENSIELT
      • HEMMELIG
      • STRENGT HEMMELIG
    • Eksempler
      • Skjermingsverdig informasjon som skal graderes dersom det kan skade nasjonale sikkerhetsinteresser at informasjonen blir kjent for uvedkommende, går tapt, blir endret eller blir utilgjengelig.

[steingod]

Good starting point. I think we probably also need to identify classification frameworks as these may change over time and differ depending on the context where data is managed. Would it be sufficient to repurpose access_constraint and extend that with various profiles?

[mortenwh]

My initial thought was also to use access_constraint so that could perhaps work

[steingod]

I assume we need to establish a more detailed structure in access_constraint then? Along the lines we have done for other elements? E.g.

<access_constraint>
    <class/>
    <classification_framework/>
</access_constraint>

Or do you think we should only use the classification above? My main concern with the text above is that it is too anchored in the legal framework in Norway, but I think we should have a classification scheme that allows a wider interpretation, e.g. aligned with the IASC data principles. Alternatively a structure like

<access_constraint>
    <class/>
    <justification/>
</access_constraint>

and a controlled vocabulary along the lines of

• Open
  • Both discovery metadata and data are open
• Protected
  • Discovery metadata are openly available, data are protected
    • Discovery metadata can be made coarser (e.g. protect information on endangered species, hydrological information in the context of WMO etc
• Closed
  • Neither discovery metadata nor data are to be made available public

In justification, references to legal constraints can be added. Such a scheme (or modified version) would be easier to reuse in other contexts.

[mortenwh]

Can we use classification_framework, and have a general classification such as the controlled vocabulary you suggested, e.g., simply named "general"?

[steingod]

Sounds ok to me, but also see that part of my original thoughts on structure didn't make it through the github editor (sorry for that). Just to make sure, you thought along these lines?

<access_constraint>
    <classification_framework>
         general
    </classification_framework>
    Open
</access_constraint>

Or perhaps better have classification_framework as an attribute like:

<access_constraint classification_framework="general">
    Open
</access_constraint>

[mortenwh]

Yes, the last one looks good to me.

[steingod]

Thoughts @ferrighi ?

[ferrighi]

I would like to avoid changing the structure of it, so eventually just add the attribute.

I don't understand the content of the attribute though. Is that a controlled vocabulary? which values should be implemented?

For the values of the field itself it is already a controlled vocabulary, which is somehow overlapping https://vocab.met.no/mmd/Access_Constraint. Should we extend this list with Protected and Closed? Perhaps update the definition of Open if needed?

[steingod]

Yes this is more opening up for other opportunities than we have today (the home grown approach). These aspects will get increasing attention in the coming years. Free and open data is challenged by the geopolitical situation and we will see more of sharing within sub communities onwards. The current vocabulary with 2 options (which could be reviewed and perhaps also potentially extended with a "semi open" option that is open for authorised users) is good for now, but insufficient in the future. Since I don't think we can foresee all constraints that may come I think having various frameworks to work within is a sound approach for now. I do think the authorised option needs more thinking anyway.

[mortenwh]

Where are we with this one now? Should someone be assigned?

[steingod]

First we need to agree on how to implement. As far as I understand @ferrighi my second option is preferred. That would play well with the semantic approach. So could we agree to implement that? If so we need to update MMD and handling of MMD as well as vocabularies.

[ferrighi]

To summarize the concept implementation:

The field will look like:

<access_constraint classification_framework="type-of-classification">value</access_constraint>

where "type-of-classification" is coming from a controlled listed called "Classification Framework" with possible values:

• "general"
• "XXX"
• "YYY"

I guess some more should be defined, but maybe for now we can have only 1 value ("general").

On the other hand, the values of access_constraint is also a controlled list, but this list changes according to the classification_framework value. So if classification_framework="general" the values must come from the vocabulary "Access Constraint General", which has allowed values: "Open", "Protected" and "Closed".

If another classification is chosen we need to provide another vocabulary and another list. Yet to be defined.

The concept works as for keywords_vocabulary and keyword, so it is in principle ok.

The issue I see would be the validation of this implementation, as the classification_framework is setting the possible values for access_constraint, and this dynamic validation cannot be done in our current xsd schema as far as I know. If validation is required, this should be solved somehow.

For the vocabulary itself, if we could use the current https://vocab.met.no/mmd/Access_Constraint for the "general" type I could deprecate all entries a part from Open and add "Protected" and "Closed".

There is need to check all translations and usage of the already published Access_Constraint vocabulary in different software, as removing concepts might break functionalities.