We need a set of common security service terms for common usage among all of the documents

[jimsch]

This was started by the use of non-repudiation in the requirements draft security considerations section. It is not clear that it was the correct term, and discussion showed that a common agreement on the term had not been reached.

This is to suggest adding definitions (perhaps just by reference) for some common security terms:

data confidentiality: The property that data is not disclosed to system entities unless they have been authorized to know the data. (From RFC 4949.)

data integrity: The property that data has not been changed, destroyed, or lost in an unauthorized or accidental manner. (From RFC 4949.)

data origination: A property that verifies the identity of a system entity that is claimed to be the original source of received data. (Derived from data origination authentication service in RFC 4949.)

authorization: An approval that is granted to a system entity to access a system resource. (From RFC 4949)

authentication: The process of verifying a claim that a system entity or system resource has a certain attribute value. (From RFC 4949.)

If you want more verbiage (for example what types of security operations are needed to provide the service), let me know what you feel is lacking and I can provide it.

[athiasjerome]

Recommend also to reuse CMMI terminology (where ISO/IEC, between others, has been used)

[henkbirkholz]

There is consensus in the group to add the following terms:

data confidentiality, data integrity, authorization, authentication.

Jim provided well suited references from RFC4949, which will be included in the terminology draft.

[henkbirkholz]

There is consensus in the group to include a term, such as Origin of Data or Data Origination, and - as a point of reference – the term Data Provenance to the terminology.

Data Origin

The current proposal “A property that verifies the identity of a system entity that is claimed to be the original source of received data.” implies the task of “verification of identity”.

• Question: Is that intentional and would this be in the scope of SACM?

There was discussion in the group about the differentiation between an “determined endpoint identity” and the “task of identifying an endpoint”. There is no final consensus about this in the group.

• Question: Is consensus regarding this a prerequisite to agree on related terminology?

Meanwhile, a slightly modified definition could be added to the terminology, as a first step:

“One or more properties that enable a SACM component to identify an Endpoint that is claimed to be the original source of received data.”

• Question: Is Original Source sufficiently self-explaining?

Data Provenance

While a “chain of custody” or “historical record” of raw (“collectible”) endpoint attributes is out of scope for SACM, there remains the question if this is also true for SACM payload transported and refined between SACM components. A core functionality of SACM is the aggregation and correlation of data to enable better refined and more complex assertions regarding endpoint posture.

• Question: Is a “historical record” in this context also out of scope for SACM?

As a first step, the following definition could be added tho the terminology:

“data provenance: a historical record of the origins and evolution of data that is influenced by inputs, entities, functions and processes.”

This example is based on definitions found in:

Pohly, Devin J., Stephen McLaughlin, Patrick McDaniel, and Kevin Butler. "Hi-Fi: collecting high-fidelity whole-system provenance." In Proceedings of the 28th Annual Computer Security Applications Conference, pp. 259-268. ACM, 2012.

and

McDaniel, Patrick, Kevin RB Butler, Stephen E. McLaughlin, Radu Sion, Erez Zadok, and Marianne Winslett. "Towards a Secure and Efficient System for End-to-End Provenance." In 2nd USENIX Workshop on the Theory and Practice of Provenance, 2010.

[athiasjerome]

The Committee on National Security Systems (CNSS) Glossary
, CNSSI No. 4009 could be used/adapted to context
Ref. https://www.cnss.gov/CNSS/issuances/Instructions.cfm

In it, "data provenance":
"In the context of computers and law enforcement use, it is an equivalent
term to chain of custody. It involves the method of generation,
transmission and storage of information that may be used to trace the
origin of a piece of information processed by community resources. Source:
ISA SSA (adapted)"

2015-07-03 12:25 GMT+03:00 henkbirkholz notifications@github.com:

There is consensus in the group to include a term, such as Origin of Data
or Data Origination, and - as a point of reference – the term Data
Provenance to the terminology.
Data Origin

The current proposal “A property that verifies the identity of a system
entity that is claimed to be the original source of received data.” implies
the task of “verification of identity”.

Question: Is that intentional and would this be in the scope of SACM?

There was discussion in the group about the differentiation between an
“determined endpoint identity” and the “task of identifying an endpoint”.
There is no final consensus about this in the group.

Question: Is consensus regarding this a prerequisite to agree on
related terminology?

Meanwhile, a slightly modified definition could be added to the
terminology, as a first step:

“One or more properties that enable a SACM component to identify an
Endpoint that is claimed to be the original source of received data.”

Question: Is Original Source sufficiently self-explaining?
Data Provenance

While a “chain of custody” or “historical record” of raw (“collectible”)
endpoint attributes is out of scope for SACM, there remains the question if
this is also true for SACM payload transported and refined between SACM
components. A core functionality of SACM is the aggregation and correlation
of data to enable better refined and more complex assertions regarding
endpoint posture.

Question: Is a “historical record” in this context also out of scope
for SACM?

As a first step, the following definition could be added tho the
terminology:

“data provenance: a historical record of the origins and evolution of data
that is influenced by inputs, entities, functions and processes.”

This example is based on definitions found in:

Pohly, Devin J., Stephen McLaughlin, Patrick McDaniel, and Kevin Butler.
"Hi-Fi: collecting high-fidelity whole-system provenance." In Proceedings
of the 28th Annual Computer Security Applications Conference, pp. 259-268.
ACM, 2012.

and

McDaniel, Patrick, Kevin RB Butler, Stephen E. McLaughlin, Radu Sion, Erez
Zadok, and Marianne Winslett. "Towards a Secure and Efficient System for
End-to-End Provenance." In 2nd USENIX Workshop on the Theory and Practice
of Provenance, 2010.

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

[henkbirkholz]

Two comments below:

"In the context of computers and law enforcement use"

There was a long discussion about the relationships between provenance, non-repudiation and their use as a legal expressions in the group. As a result, both the term "chain of custody" and the context "law" are excluded from the scope of the definitions in SACM, at the moment.

• Question: Should this be highlighted in the definition of data provenance, explicitly?

"method of generation, transmission and storage of information that may be used to trace"

Interestingly, there is no mentioning of "evolution" in this definition. Strictly interpreted, there seems to be no record of alteration of the data after its original creation in this law-specific version of data provenance - this definition seems to be solely about "tracing" it.

• Question: Is the refinement of payload during the SACM process (e.g. raw & complex assertions) supposed to be part of the data provenance concept in SACM?

While providing this detailed record to express data provenance in the context of SACM is out of scope in this iteration, it might not be in future iterations or versions of SACM.

• Question: Should the definition from CNSS be incorporated or referenced by the terminology draft?

[jimsch]

Data Origin

• Question: implies the task of “verification of identity” Is that intentional and would this be in the scope of SACM?

I believe that this task is in the scope of SACM and is a function of the initial recipient of a piece of data. The verification of identity can be either based on a cryptographic object or based on the transport protocol. The question of what a SACM component needs to do if information is published to the system from a component that cannot authenticate itself in some manner is open. (T-004 is relevant.)

• Question: differentiation between an “determined endpoint identity” and the “task of identifying an endpoint” - Not sure that this is relevant to what we are discussing here - can you elucidate why you think it is.
• Question:Is Original Source sufficiently self-explaining? It is to me.

Data Provenance

• Question: Is a “historical record” in this context also out of scope for SACM?

DM-011 Data Generation appears to state that this is a requirement. One must be able to publish what was used in order to get to a specific point.

I am not sure what you mean by historical record, but both 'IM-005 Data Lifetime Management' and the fact that an attribute could be published by multiple sources would imply to me that there is to ability in SACM to have some degree of a "historical record".

A different question that might need to be asked is should there be a way to go forward, i.e. from an attribute to a new attribute based on that one as well as backwards.

[henkbirkholz]

Data Origin and Data Source are differentiated and defined for a long time now.

Data Provenance is now well-defined and the most basic attributes to express them are included in the IM. Specific metadata subjects can be added to the IM later or due to extensions of the IM even more later.