Definition of "Asset"

[jimsch]

The definition of "asset" needs to be expanded.

In the Information model, the term "asset" is defined as follows: In this context an "asset" refers to "anything that has value to an organization" (see [NISTIR-7693]).

This is reasonable close to the definition of "asset" that is used in the requirements document (See item 1 in section 2)

Based on the current definition it is not clear that everything that the IM and requirements consider to be assets are in fact assets. For example, while it is clear that a device or a piece of software is an asset. It is not clear to me that a USB port on a device or a user's identity would also be defined as an asset. My expectation is that, at a minimum, every box in the top half of figure 1 in the information model document is an asset. This should be better reflected in the definition.

[athiasjerome]

I agree. An Asset could have Components These Components could be Assets or just Components Each Component could have Components ...

Note that while it requires a more granular definition than in rfc5209, I tried to define this in my XORCISM project

[athiasjerome]

Suggest to develop a description of the abstract concept of "Asset Characterization" as a combination/aggregate of various identifiers. Also recommend to reuse ISO/IEC Asset definition.

[athiasjerome]

Also recommended reading: https://www.commoncriteriaportal.org/cc/ "operational environment" must be taken into consideration for evaluation

[henkbirkholz]

Various Related References

ISO/IEC 27000:2014

It seems the term Asset was dropped from Section 2 “terms and definition” in ISO/IEC 27000:2014? (http://standards.iso.org/ittf/PubliclyAvailableStandards/c063411_ISO_IEC_27000_2014.zip)

Common Criteria

Definitions from CC (https://www.commoncriteriaportal.org/files/ccfiles/CCPART1V3.1R4.pdf):

"target of evaluation (TOE): set of software, firmware and/or hardware possibly accompanied by guidance." "operational environment: environment in which the TOE is operated" "component TOE: successfully evaluated TOE that is part of another composed TOE" "composed TOE: TOE comprised solely of two or more components that have been successfully evaluated" "functional interface: external interface providing a user with access to functionality of the TOE which is not directly involved in enforcing security functional requirements".

Question: Can a Target Endpoint be interpreted as a specialization of a TOE?

802.1AR

There also is the definition of Aggregate Device from IEEE 802.1ar: “aggregate device: A device containing multiple logical or physical devices.” But device is different from endpoint in that specific “secure device identifier” context: “device: A device is any entity that has a single IDevID credential.”

RFC4949

The definition of Asset from RFC4949 (Internet Security Glossary, Version 2) seems to be quite specific due to the context of the RFC: “(I) A system resource that is (a) required to be protected by an information system's security policy, (b) intended to be protected by a countermeasure, or (c) required for a system's mission.”

Usage in SACM

Asset is currently defined in the terminology draft and the information model (in section 4.1. "Software Component"). The definitions are basically a reference to RFC4949. There is a conflicting definition in the "attic" of the IM draft in section B.1.1. "Pre-defined and Modified Terms", which exeeds the scope of Endpoints ("anything that has value to an organization").

The requirements draft (“the assets composing an endpoint”) and the use-cases draft (“endpoints and the assets they are composed of”) indicate that endpoints are composed of assets. The information model draft highlights that “hardware components may also be assets and/or harmful”.

On one hand, it seems that there is implicit consensus that endpoints are composed of assets. On the other hand, outside of SACM Asset seems to be the more general term compared to Endpoint.

Question: Is there actually consensus about Assets being the components of Endpoints?

Unfortunately, defining Assets as "components of endpoints" or "building blocks of endpoints" might raise a new issue: Component is an already used as a vital term in the architecture draft and Building Blocks is already defined in the terminology draft.

Question: Would defining and differentiating SACM Components and Endpoint Components (e.g. Hardware Component or Software Component) improve the current situation? Question: Do we need the term Asset for more than a point of reference (included mabye in the definition of Endpoint or potentially Endpoint Component)?

[adammontville]

What if we expand the definition of asset to recognize that assets are composite in nature? Such a recognition would not interrupt the RFC4949 definition of asset too much, and may obviate the need to differentiate between SACM Components and Endpoint Components.

Jim's initial examples of USB port and user identity, both of which exist as part of an endpoint, the composite view of asset coupled with RFC4949 (I)(a) qualification of "asset" would seem to be covered.

[sacm]

Does that include Samsung trojanning Usb updates by blocking all windows updates?

Best Regards,

Dave

david.misell@bcs.org 07710380044 misell.dave on skype

On 19 Jul 2015, at 10:23, adammontville notifications@github.com wrote:

What if we expand the definition of asset to recognize that assets are composite in nature? Such a recognition would not interrupt the RFC4949 definition of asset too much, and may obviate the need to differentiate between SACM Components and Endpoint Components.

Jim's initial examples of USB port and user identity, both of which exist as part of an endpoint, the composite view of asset coupled with RFC4949 (I)(a) qualification of "asset" would seem to be covered.

— Reply to this email directly or view it on GitHub.

---

sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm

[llorenzin]

During our discussion this morning, we were struggling to grasp the relationships between an endpoint, an asset, and an attribute, and we realized that the definition of "asset" in the terminology draft is not sufficiently clear for our purposes. We clarified among ourselves that:

An asset can be composed of other assets An endpoint is composed of assets An endpoint is itself an asset

An attribute is a property of an endpoint, and it's more specifically a property of an asset on an endpoint

Examples: User account existing on a machine = asset Hardware component = asset Software component = asset Logged-in user = attribute

This seems to be relevant to multiple definitions (asset, attribute, endpoint) so perhaps we need a separate section on relationships between terms?

[djhaynes]

Based on discussion from the Endpoint ID Design Team meeting, we should consider making it explicit that an asset is not necessarily owned by an organization. This will help reduce confusion as some readers may imply that it is. From a SACM modeling perspective, we should not care who owns it.

[djhaynes]

Not critical, but, I might also include hardware, software, and identity in the list of types of assets.

[jimsch]

I agree that ownership would be a good clarify.

I also wanted to include software packages in the list of asset types. I was not sure that I thought that guidance was an asset. Can you clarify why it should be thought of as an asset?

[djhaynes]

Just to clarify, when you say "software package", are referring essentially to software before it is installed (i.e. installation media) on the endpoint and becomes a "software component"?

Regarding guidance as an asset, here are some of my thoughts.

(1) An asset is "a system resource that is (a) required to be protected by an information system's security policy, (b) intended to be protected by a countermeasure, or (c) required for a system's mission." I think guidance can satisfy this from a couple perspectives. First, from a vendor that publishes guidance (their intellectual property) to its customers. A vendor will want to protect this guidance from being maliciously altered or otherwise corrupted as providing this content to its customers will not be good for business. Second, from an end-user organization perspective, guidance can be very sensitive and thus required to be protected as it can provide a lot of information that (if in the hands of an attacker) could really hurt the organization. Think about collection and evaluation guidance which could provide and attacker with information such as the endpoints that are on the network, what software they are running, what kind of security controls they are using and how they are set, etc.

(2) A system resource is "(I) Data contained in an information system; or a service provided by a system; or a system capacity, such as processing power or communication bandwidth; or an item of system equipment (i.e., hardware, firmware, software, or documentation); or a facility that houses system operations and equipment. (See: system component.)". I don't think this definition excludes guidance which could probably be classified under data or maybe even system equipment (i.e. machine readable assessment documentation).

[sacm]

Hello,

The RFC4949 definition supports information being an asset and this is common for asset definitions. Guidance is a type of information that one might want to protect, so it logically follows.

$ asset (I) A system resource that is (a) required to be protected by an information system's security policy, (b) intended to be protected by a countermeasure, or (c) required for a system's mission.

I am hoping this can be wrapped up quickly as the discussion on this term has been going on for a while now.

Thank you, Kathleen

On Fri, Sep 25, 2015 at 11:01 AM, Danny Haynes notifications@github.com wrote:

Just to clarify, when you say "software package", are referring essentially to software before it is installed (i.e. installation media) on the endpoint and becomes a "software component"?

Regarding guidance as an asset, here are some of my thoughts.

(1) An asset is "a system resource that is (a) required to be protected by an information system's security policy, (b) intended to be protected by a countermeasure, or (c) required for a system's mission." I think guidance can satisfy this from a couple perspectives. First, from a vendor that publishes guidance (their intellectual property) to its customers. A vendor will want to protect this guidance from being maliciously altered or otherwise corrupted as providing this content to its customers will not be good for business. Second, from an end-user organization perspective, guidance can be very sensitive and thus required to be protected as it can provide a lot of information that (if in the hands of an attacker) could really hurt the organization. Think about collection and evaluation guidance which could provide and attacker with information such as the endpoints that are on the network, what software they are running, what kind of security controls they are using and h ow they are set, etc.

(2) A system resource is "(I) Data contained in an information system; or a service provided by a system; or a system capacity, such as processing power or communication bandwidth; or an item of system equipment (i.e., hardware, firmware, software, or documentation); or a facility that houses system operations and equipment. (See: system component.)". I don't think this definition excludes guidance which could probably be classified under data or maybe even system equipment (i.e. machine readable assessment documentation).

— Reply to this email directly or view it on GitHub https://github.com/sacmwg/draft-ietf-sacm-terminology/issues/1#issuecomment-143245997 .

---

sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm

Best regards, Kathleen

[jimsch]

When I say "software package" I am of installed software. I used package because I was thinking in terms of Office which has several different components that are themselves assets as well. I am not tied to the string "package" - simply software is just fine with me.

From the argument you have expressed about guidance, would you also say that an "posture assessment" is also an asset? It can be thought of as having the same issues as you posited for "guidance". (Mostly curiosity not a change in the document.)

[djhaynes]

Sorry for the delay, I was out of the office last week.

Regarding "software package", thanks for the clarification Jim. When I saw package, I immediately thought of a package on Linux. If you are not particularly tied to it "software package", I think I would prefer "software" with the understanding a piece of software could be composed of other software.

To answer your question Jim, yes, I think "posture assessment information" (e.g. data collected from an endpoint, evaluation results, etc.) would also be classified as an asset.

Thanks for the feedback Kathleen. +1 to using the RFC4949 definition of "asset" and closing out this issue.

[jimsch]

"software" is just fine with me.

[sacm]

Hi,

Agreed - simple "software" is just fine with me.

Cheers,

• Ira

Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434

On Wed, Oct 7, 2015 at 1:04 AM, Jim Schaad notifications@github.com wrote:

"software" is just fine with me.

— Reply to this email directly or view it on GitHub https://github.com/sacmwg/draft-ietf-sacm-terminology/issues/1#issuecomment-146078246 .

---

sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm

[henkbirkholz]

Addressed on multiple levels, multiple times.