Subject: [sacm] A potential outline of Identifying Attributes section of Information Model

From: Clifford Kahn <[email-masked]>
Date: Fri, 22 May 2015 03:13:58 +0000

All,
This is mainly for the IDT. I said I would produce an outline for us to bash on our call this Friday, 5/22.
I haven't yet figured out how to use github, so please excuse my use of this archaic method, email.
Best,
                                                Cliff
4.x. Identifying Attributes
(State the goals.)
Want a consumer to be able to tell whether two endpoint attribute assertions concern the same endpoint.
Therefore, we specify attributes that enable a consumer to discern this.
(Why this is not simple)

4.x.1. Common Identifying Attributes
(With MUST/SHOULD/MAY language about
* when and whether an endpoint attribute assertion is to include the attribute
* what the attribute says about the endpoint -- the *meaning* of the attribute
* range of values (mostly by reference to other RFCs)
)
*         IP address
*         MAC address
*         Hardware serial number
*         Certificate
*         Public key
*         Tool-specific identifier
*         ...
(Minor side note: "Tool-specific identifier" suggests that two tools could never agree on a tool-specific identifier. But a community may agree on one, and might even create a formal standard. So I don't think they are tool-specific. I think all that's important is that each of these attributes has a type and meaning *not* specified by the SACM internet drafts. Not sure what to call them.)

4.x.2 Properties of Attributes
(Explain each)
* Stability
                volatile - persistent - mutable
* Multiplicity:
* Does the value generally refer to only one endpoint, or to multiple?
* Does an endpoint generally have multiple values of the attribute, or only one?
* Accuracy:
How often is the value true vs false? What can make a false value happen? (Lying endpoint? etc)
* Commonness
(Or other language; I found that the terms from 4.11.2 in https://tools.ietf.org/html/draft-ietf-sacm-information-model-01#page-19 were not bad at all, and adapted them.)

(Matrix of attributes and their properties)

(Is there any normative language in this section? Or is it just a set of things for consumer implementers to consider?)

4.x.3. Identification of Endpoints where SACM Components Reside
Every information element needs identifying attributes of its producer's endpoint. (Provide normative language. SHOULD? MUST?)
Specifically, in an endpoint attribute assertion, we need identifying attributes of the asserter's endpoint. If the asserter is external, the assertion will contain identifying attributes of two endpoints.
(Discuss what this information is for.)

4.x.4. Security Considerations
Effects of misidentification
Things that can cause misidentification
How minimize misidentification

Appendix: Examples of Endpoint Identification in Action
(Some of our test cases)

Appendix: Mapping to SACM Use Cases and Requirements

Clifford Kahn
Principal Engineeer, Technical Lead

---

From: "Wolfkiel, Joseph L CIV DISA ID (US)" <[email-masked]>
Date: Fri, 22 May 2015 12:43:22 +0000

Is this the only identification section?  I commonly have other identification goals in addition to being able to assign findings from different sensors to the same endpoint, for example:

1.  Identifying a physical or logical location where an endpoint may be accessed, either for validation of findings or remediation/mitigation and other attributes to assist in the differentiating between endpoints that may exist at the same location (e.g. "the red iPhone owned by Mr Jones, in building 3, 2nd floor, room 213, cubicle 16, with a dent on the upper right side, serial number 15SQ67B12", telephone number 345-123-6543)
2.  Identifying a particular assessment target on an endpoint (e.g. a particular piece of software, a database instance, web site, etc) 

Would it also be useful to provide some sample business logic showing how identification attributes can/would be used?  Maybe even define a few standard matching algorithms, along with a preference for each, based on the probability of correct identification using each one?

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52
Work: (301) 225-8820
Gov Cell: (571) 814-8231
[email-masked]

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Clifford Kahn
Sent: Thursday, May 21, 2015 11:14 PM
To: [email-masked]
Subject: [sacm] A potential outline of Identifying Attributes section of Information Model

All,

Best,

                                                Cliff

(State the goals.) 

(Why this is not simple)

)

.         IP address

.         MAC address

.         Hardware serial number

.         Certificate

.         Public key

.         Tool-specific identifier

.         ...

(Explain each)

* Stability

* Multiplicity:

* Accuracy:

* Commonness

(Or other language; I found that the terms from 4.11.2 in https://tools.ietf.org/html/draft-ietf-sacm-information-model-01#page-19 <https://tools.ietf.org/html/draft-ietf-sacm-information-model-01#page-19>  were not bad at all, and adapted them.)

(Some of our test cases)

 

Clifford Kahn

---

From: Jerome Athias <[email-masked]>
Date: Fri, 22 May 2015 16:20:37 +0300

Dear Joseph,

I do appreciate the kind reminder around location related meta data.

Following OVAL lesson learned/recommandations:
Joseph, could you be one of our operational Asset Management domain SME?
Ref. draft-hansbury-sacm-oval-info-model-mapping-00 6.4.2.
That would help for per-domain-consensus (for Domain-driven design).

I would suggest reuse or extension of the Asset Identification NISTIR
7693. (Unless NDDM > 0.4 available)
Any comment?

With KISS in mind, we should conclude on the minimum endpoint's
identifying attributes.
(I would prefer to be able to use SACM -right now-, for only one
simple use case, with the restriction of just being able to use IPv4
addresses, than still managing my stuff without Automation)

Best regards

2015-05-22 15:43 GMT+03:00 Wolfkiel, Joseph L CIV DISA ID (US)
<[email-masked]>:
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>