Subject: [sacm] Terms and Definitions (was RE: SACM Charter Focused)

From: "Waltermire, David A." <[email-masked]>
Date: Tue, 22 Jan 2013 21:50:38 -0500

I stubbed out a glossary section for the Use Cases document, but didn't include it in the most recent draft since I didn't have any associated definitions.  There is a mixture of terminology used within the draft.  It would be useful to tighten down the terms used to a smaller set.  The following terms/definitions would go a long way to addressing this and would also set us up to talk more succinctly relative to the use case and architecture documents.

* Asset - ISO/IEC 27001:2005 defines an asset as: "Any tangible or intangible thing that has value to an organization."

Short and sweet.  Got this off a web reference.  I don't have a copy of the doc right now.  I'll double check it tomorrow.

We use a similar definition at NIST in NISTIR 7693 section 2.1 (http://csrc.nist.gov/publications/nistir/ir7693/NISTIR-7693.pdf): "Anything that has value to an organization, including, but not limited to, another organization, person, computing device, information technology (IT) system, IT network, IT circuit, software (both an installed instance and a physical instance), virtual computing platform (common in cloud and virtualized computing), and related hardware (e.g., locks, cabinets, keyboards)."

Also from SP 800-30r1 (http://csrc.nist.gov/publications/nistpubs/800-30-rev1/sp800_30_r1.pdf) relative to "organizational assets": "The term organizational assets can have a very wide scope of applicability to include, for example, high-impact programs, physical plant, mission-critical information systems, personnel, equipment, or a logically related group of systems. More broadly, organizational assets represent any resource or set of resources which the organization values, including intangible assets such as image or reputation.

This encompasses software and endpoints as assets.

* Endpoint - Reference RFC 5209 section 2 (http://tools.ietf.org/html/rfc5209#section-2) definition: "Any computing device that can be connected to a network. [snip] This includes: laptops, desktops, servers, cell phones, or any device that may have an IP address."

* Posture - Reference RFC 5209 section 2 (http://tools.ietf.org/html/rfc5209#section-2) definition:  "Configuration and/or status of hardware or software on an endpoint as it pertains to an organization's security policy".

This can be used to represent the state information that is collected from the endpoint.

* Assessment - Reference RFC 5209 section 2 (http://tools.ietf.org/html/rfc5209#section-2) definition:  "The process of collecting posture for a set of capabilities on the endpoint (e.g., host-based firewall) such that the appropriate validators may evaluate the posture against compliance policy."

Not sure this exactly maps to our use of "assessment", since compliance validation is only one possible use of collected information.  It doesn't address other uses for situational awareness over endpoints such as vulnerability detection, license management, etc.  The term "capabilities" might map to software or software components in our case.

* Attribute - Reference RFC 5209 section 2 (http://tools.ietf.org/html/rfc5209#section-2) definition:  "Data element including any requisite meta-data describing  an observed, expected, or the operational status of an endpoint  feature (e.g., anti-virus software is currently in use)."

* Posture Attributes - Reference RFC 5209 section 2 (http://tools.ietf.org/html/rfc5209#section-2) definition:  "Attributes describing the configuration or status (posture) of a feature of the endpoint.  For example, a Posture Attribute might describe the version of the operating system installed on the system."

This can be used to represent a specific assertion about endpoint state (e.g. configuration setting, installed software, etc.)  Also assumes that installed software or software components are a "feature of the endpoint".

Does anyone have any concerns with using the these terms/definitions?

Sincerely,
Dave

-----Original Message-----
From: Stephen Hanna [mailto:[email-masked]]
Sent: Monday, January 21, 2013 3:57 PM
To: Allan Thomson (althomso); Waltermire, David A.; [email-masked]'
Subject: RE: [sacm] SACM Charter Focused

Allan,

I'm glad that we have agreement on the concepts.
Now we can figure out the right words.

RFC 5209 defines an endpoint as "Any computing device that can be connected to a network." It further states "This includes: laptops, desktops, servers, cell phones, or any device that may have an IP address." So I think that a router, switch, firewall, or wireless access point would be included. These days, a VOIP phone, thermostat, printer, automobile, or household appliance might well also fall into this category. And that's a good thing.
We don't need to invent different protocols for assessing the security posture of a printer vs. a laptop vs. a router. The NEA protocols were designed to be flexible enough to accommodate the particular needs of different kinds of devices. For example, the IEEE Printer WG is defining for printer-specific attributes that are designed to go into the NEA protocols. See these docs:

ftp://ftp.pwg.org/pub/pwg/ids/wd/wd-idsattributes10-current.pdf

ftp://ftp.pwg.org/pub/pwg/ids/wd/wd-ids-tnc10-current.pdf

Similarly, "posture" is defined in IETF RFC 5209 as "Configuration and/or status of hardware or software on an endpoint as it pertains to an organization's security policy".

Given the broad definition of endpoint earlier in that document (which is an IETF RFC) and the use of these same terms across the NEA standards (like RFC 5792 and RFC 5793), I think we have well-established words for the devices/endpoints/thingies whose security configuration/posture/whatever we are assessing. I'm sure that there are many words for the same concept across all the different communities of interest. VOIP phone manufacturers and standards groups probably use a different term than printer manufacturers or auto manufacturers or appliance manufacturers.
But we should settle on a single term for each concept here in the SACM community.

Since the terms "endpoint" and "posture" are used in the NEA standards and those are IETF Standards-track RFCs that we'll probably be reusing and building on in SACM, I suggest that we use the same terms in SACM.

And once we settle this wording issue, I totally agree that the charter should be clarified to explicitly state that we're focused on posture assessment of endpoints. Assuming, that is, that there is rough consensus on this on the list.

Thanks,

Steve

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Allan Thomson (althomso)
> Sent: Monday, January 21, 2013 3:11 PM
> To: Stephen Hanna; Waltermire, David A.; [email-masked]'
> Subject: Re: [sacm] SACM Charter Focused
>
> Hi Steve -
>
> I agree configuration or posture is not static and it definitely
> changes over time.
>
> My concern about using the word "posture" is that it has been
> primarily used to represent endpoint state (including the NEA
> reference you
> included) whereas for switches/routers...etc state it is typically
> referred to as configuration.
>
> I think we are agreeing semantically on what
> static/configuration/posture assessment represents. If there is a term
> that can be used equally for both categories of network/endpoint
> assessment then great. I'm not strongly tied to any particular term
> provided it is representative and well understood of the assessment
> being performed.
>
> It would seem the 2nd term behavior is already in good understanding
> :-
> )
>
> If we could clarify that the charter and focus on UC1 are focused
> solely on posture/configuration assessment that would be good to add.
> Perhaps consider explicitly stating that behavior assessment is not
> part of the charter to avoid confusion in future.
>
> Regards
>
> allan
>
> On 1/19/13 6:58 AM, "Stephen Hanna" <[email-masked]> wrote:
>
> >I'm glad that Allan has raised these valuable issues.
> >Some will need to be addressed in the Use Cases and Requirements
> >document, some in the Architecture document, and some in the charter.
> >Still, all of them are important.
> >
> >I agree with the views that Dave and Gunnar expressed.
> >
> >I would suggest one change in terminology. Where Allan used these
> >terms:
> >
> >> A) Configuration/Static
> >> B) Behavioral/Dynamic
> >
> >I would suggest these terms instead:
> >
> >> A) Posture
> >> B) Behavior
> >
> >The IETF NEA Working Group previously defined Posture in RFC 5209
> >(the NEA Overview and Requirements spec):
> >
> >>   Posture - Configuration and/or status of hardware or software on
> an
> >>      endpoint as it pertains to an organization's security policy.
> >
> >I believe that's what Allan refers to in this definition:
> >
> >> Static:
> >> - you assess a system's "security" by verifying compliance with a
> >> configuration policy (e.g allowed applications or configuration
> rules)
> >> - typically is a direct communication with the system
> >
> >The problem that I have with the term "Static" is that posture is not
> >static. It changes, as Dave pointed out.
> >An endpoint can get infected or have a new program installed on it or
> >have its configuration changed.
> >Alternatively, the security policy can change, meaning that a
> >previously compliant endpoint no longer is so.
> >
> >And I do agree that for UC1, we're only focused on assessing the
> >Posture of an endpoint. Not on Behavior, at least for now. Any
> >disagreement? Agreement?
> >
> >I would point out that there are many ways of determining posture. If
> >the endpoint supports the NEA protocols, you can use those to
> >interrogate the endpoint. If it doesn't (and even if it does), you
> >can employ other techniques such as sending commands to the endpoint,
> >installing an agent on the endpoint, or even just observing its
> >traffic to see whether it's acting like a VOIP phone or a Windows 7
> >system. I believe that we want to support all these techniques in
> >SACM. Do others agree? Disagree?
> >
> >Thanks,
> >
> >Steve
> >
> >> -----Original Message-----
> >> From: Waltermire, David A. [mailto:[email-masked]]
> >> Sent: Friday, January 18, 2013 10:35 PM
> >> To: Allan Thomson (althomso); Stephen Hanna; [email-masked]'
> >> Subject: RE: [sacm] SACM Charter Focused
> >>
> >> Allan,
> >>
> >> I hit send too quickly.  Your post is well-thought out and very
> >> insightful.  More comments inline.  Does anyone else have a
> different
> >> view?
> >>
> >> Dave
> >>
> >> -----Original Message-----
> >> From: Waltermire, David A.
> >> Sent: Friday, January 18, 2013 10:19 PM
> >> To: 'Allan Thomson (althomso)'; Stephen Hanna; [email-masked]'
> >> Subject: RE: [sacm] SACM Charter Focused
> >>
> >> Allan,
> >>
> >> In general, I'd like to see us not reinvent new terminology.  There
> are
> >> plenty of sources of internationally agreed upon terms that we can
> pull
> >> from (e.g. ISO).  We should look to use such terms as much as
> possible.
> >> More comments are inline below marked [DAW].
> >>
> >> Sincerely,
> >> Dave
> >>
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf
> Of
> >> Allan Thomson (althomso)
> >> Sent: Friday, January 18, 2013 11:10 AM
> >> To: Stephen Hanna; [email-masked]'
> >> Subject: Re: [sacm] SACM Charter Focused
> >>
> >> Hi - Apologize for the delay in reviewing the charter document that
> >> Steve sent out.
> >>
> >> I have several questions and comments that may influence the
> >> charter writeup. Appreciate if the group consider them.
> >>
> >> 1) Need a crisp definition of "Security assessment"
> >>
> >> - We need to clearly define what security aspects are being
> >> assessed and from what perspective.
> >> - There are at least 2 forms of assessing a system.
> >>
> >> [DAW: Do you know of an existing definition (preferred) or have a
> good
> >> definition in mind?]
> >>
> >> A) Configuration/Static
> >> B) Behavioral/Dynamic
> >>
> >> Static:
> >> - you assess a system's "security" by verifying compliance with a
> >> configuration policy (e.g allowed applications or configuration
> rules)
> >> - typically is a direct communication with the system
> >>
> >> Dynamic:
> >> - you assess a system's "security" by assessing observed
> >> behavior/logs/statisticsŠ..etc by gathering information from
> multiple
> >> network & security infrastructure devices with information on the
> >> system you are assessing
> >> - typically the assessment does not talk directly to the system
> being
> >> assessed at all
> >> - in many cases the system being assessed for security is not aware
> of
> >> the systems that are providing security telemetry to the assessing
> >> system
> >>
> >> I believe the intent of this group is only the Configuration/Static
> >> category I have described. Is that correct? If so, it would be
> helpful
> >> to clarify that the group is not trying to solve the second case.
> >> If the group intends to solve both then it would be helpful to
> understand
> >> the nature/characteristics of protocols for both use cases. They
> >> are often times necessarily very different protocols.
> >>
> >> Clarifying the expectations in the charter will help define the
> scope
> >> of the group's work.
> >>
> >> [DAW: This is a great question.  I believe we are focused (at least
> >> initially) on what you call the "static" aspects.  Most of our
> >> discussions have been around standardizing how we assess the host
> for
> >> software inventory, configuration and vulnerability concerns.  We
> are
> >> focusing on ways to get assertions about a devices security posture.
> >> In the long-run, I'd like to see us integrate other sources of
> >> information related to what you are calling "dynamic".  This will
> >> enable implementations to correlate what the devices state is with
> how
> >> it is behaving on the network.  This will help in detecting if the
> >> device is lying to us about its state.  This type of synthesis is
> where
> >> continuous monitoring can become very powerful.  To get there we
> need
> >> to walk before we run. ;-)
> >>
> >> On a side note, I prefer the notions of periodic vs. real-time.
> >> Assessment of configuration policy has traditionally be performed
> >> on
> a
> >> periodic basis based on fairly static configuration content, but it
> >> doesn't have to work this way.  Many operating systems and
> applications
> >> support API hooks that allow you to monitor changes to
> >> configuration artifacts (e.g. registry keys, files, etc.)  If we
> >> used these capabilities, it would be possible to monitor
> >> configuration and software changes in real-time.  Granted, there
> >> may be performance concerns with such an approach.  Doing this may
> >> also enable us to
> have
> >> more visibility into what is happening on the device during an
> attack,
> >> but before the device is compromised.  Of course if this is all
> >> happening in memory, we may need to use other sources of
> >> information anyway.]
> >>
> >> 2) "The working group will achieve this by enabling the exchange of
> >> shared Intelligence"
> >>
> >> - What specific intelligence are you referring to? There are other
> >> forums and groups working on intelligence sharing and is it the
> >> goal
> of
> >> this group to take on those charters too?
> >> - There are many examples but here are two that come to mind right
> >> away:
> >>         A) IODEF/RID enables some level of sharing intelligence
> >> that aids in security assessment.
> >>         B) Multiple security vendors have the concept of reputation
> >> and/or blacklists and have protocols to distribute that information
> to
> >> aid in the improved assessment of the network security.
> >>
> >> - It would seem that this group is focused on assessing security of
> >> endpoints/servers where "intelligence" feeds may influence an
> >> assessment
> >> - how that intelligence is gathered/authorized for access...etc is
> very
> >> different from potentially the direct communication with the
> >> endpoint/server for assessment.
> >> - Please clarify the term intelligence and its use in the charter.
> >> - Is it to distribute intelligence information from multiple
> >> sources
> to
> >> consumers of that intelligence.
> >> - Is intelligence gathering and distribution part of the charter at
> >> all?
> >>
> >> [DAW: I see the SACM use cases as clients of any intelligence
> >> capabilities.  SACM-based solutions would consume indicator and
> >> detection signatures and potentially use them for device assessment.
> >> If we get to addressing UC2, Enforcement of Acceptable State, we
> >> may
> be
> >> able to use countermeasures provided by intelligence capabilities
> >> to affect enforcement/remediation.  If we get to addressing UC3,
> Security
> >> Control Verification and Monitoring, we may become part of the
> >> automation infrastructure that can be used to provide state
> information
> >> that can be incorporated into incident handing and coordination
> >> processes.]
> >>
> >> 3) It may be helpful to the charter to define what is actually
> >> being assessed from a security perspective.
> >>
> >> - Similar to 1) above the configuration has many aspects including:
> >> A) software including: firmware (BIOS, OS), applications installed
> >> B) user configuration settings (login policy, password
> settingsŠ.etc)
> >> C) network/application configuration (such as router configuration,
> >> laptop network interface configuration, firewall settingsŠ.etc)
> >>
> >> Is the intent of this group to gather all of this information for
> >> "security assessment"?
> >>
> >> If so, what requirements have been defined and must be established
> for
> >> systems being assessed to gather all of this information? Some that
> >> come to mind are things like latency, volume of data, data access
> >> control, authenticity of the data, number of systems expected in a
> >> single assessment domain (e.g.
> >> 100s -> 100ks?), version control of assessment protocols Š.etc to
> >> ensure large environment can be assessed even when multiple
> >> versions
> of
> >> the "assessment protocol" are deployed
> >>
> >> [DAW: I believe all of these assessment types are in-scope.  As far
> as
> >> scale, this is something that we will need to address.  As we work
> >> through improving the use case and develop the architecture
> documents,
> >> it would be great if you keep us focused on these concerns by
> providing
> >> feedback.  If we are missing any of these requirements, please
> >> raise any concerns.]
> >>
> >> 4) The charter describes a "content repository" and a protocol to
> >> access this repository
> >>
> >> - Given that there are likely multiple systems assessing different
> >> aspects of security its not clear to me how a single content
> repository
> >> (even if
> >> logical) is practical or correct
> >>
> >> [DAW: I agree with Gunnar.  There is no assumption of a single
> >> repository.  It is possible that different repos will focus on
> >> different data domains.  I also strongly believe that we need to
> build
> >> fault tolerance into any repository solution supporting federation,
> >> caching, and clustering concepts.]
> >>
> >> - It may be better to think of the charter and protocols in terms
> >> of logical entities/actors such as:
> >> A) Security assessor
> >> B) Security Assessee
> >> C) Security Telemetry Publisher
> >> D) Security Telemetry Consumer
> >>
> >> If there are better "standard" terms for these entities/actors
> should
> >> we adopt that taxonomy as the basis for the group's work? It would
> seem
> >> there are possibly some options to consider.
> >>
> >> Subsequently, the protocols and interfaces would then be defined
> >> utilizing those Terms instead of the actors instead of content
> >> repository.
> >>
> >> [DAW: I am not sure I follow.  There is a difference between the
> >> infrastructure components that support various roles/processes and
> the
> >> roles/processes themselves.  In my opinion we are defining the I/O
> for
> >> and maybe to some extent the function of the infrastructure
> components.
> >> You could call these things entities/actors, but it is possible to
> >> define the same protocol for exchanging information between
> different
> >> combinations of actors.]
> >>
> >> 5) Enabling vendors (networking; security; server; applications,
> >> combinations
> >> thereof) will understand how to assess the security of their
> respective
> >> technologies. The idea that a single assessor will be created that
> is
> >> all knowledgeable about all aspects of technology in the
> >> environment
> is
> >> limiting. We should consider the idea that there is a set of
> >> technologies (applications, configurations, networksŠ.etc) that
> >> must
> be
> >> assessed by appropriate security assessment systems. That means
> there
> >> is NO single system doing that. There *may* be one but today there
> are
> >> multiple and likely that will continue for good technology reasons
> and
> >> business reasons.
> >>
> >> The charter should define the protocols to enable multiple vendor
> >> interoperability without mandating that all security information or
> >> assessment thereof has to be done utilizing a single content
> >> repository.
> >>
> >> [DAW: I agree.]
> >>
> >> My 10cents.
> >>
> >> Allan Thomson
> >>
> >>
> >>
> >> On 1/17/13 10:09 AM, "Stephen Hanna" <[email-masked]> wrote:
> >>
> >> >Here (attached and below) is a new version of the proposed SACM
> >> charter
> >> >that makes these changes:
> >> >
> >> >* Added two deliverables: a SACM Architecture document and
> >> >  a Use Cases and Requirements document
> >> >
> >> >* Changed our areas of focus to be system security assessment
> >> >  and interacting with content repositories
> >> >
> >> >* Removed the exchange of information across organizational
> >> >  boundaries
> >> >
> >> >Please review this text and raise any concerns or questions.
> >> >And look out for another email from me suggesting more
> simplifications
> >> >and clarifications to the charter.
> >> >
> >> >Thanks,
> >> >
> >> >Steve
> >> >
> >> >--------
> >> >
> >> >Proposed Working Group Charter
> >> >
> >> >Name: Security Automation and Continuous Monitoring (SACM)
> >> >AREA: Security
> >> >
> >> >Chairs:
> >> >TBD
> >> >TBD
> >> >
> >> >Security Area Directors:
> >> >     Stephen Farrell <stephen.farrell at cs.tcd.ie>
> >> >     Sean Turner <turners at ieca.com>
> >> >
> >> >Security Area Advisor:
> >> >     Sean Turner <turners at ieca.com>
> >> >
> >> >Mailing Lists:
> >> >     General Discussion: sacm at ietf.org
> >> >     To Subscribe:       http://www.ietf.org/mailman/listinfo/sacm
> >> >     Archive:            http://www.ietf.org/mail-archive/web/sacm
> >> >
> >> >Description of Working Group
> >> >
> >> >Securing information and the systems that store, process, and
> transmit
> >> >that information has become a challenging task for organizations
> >> >of
> >> all
> >> >sizes, and we find that security practitioners spend most of their
> >> time
> >> >on manual processes relegating them to ineffectiveness. Security
> >> >automation to verify system configurations with the ability to
> >> >prioritize risk based on increased situational awareness from
> shared
> >> >intelligence is the key to escaping this rut. This working group
> will
> >> >develop security automation protocols and data format standards in
> >> >support of information security processes and practices where
> >> >practical. These standards will help security practitioners to be
> >> >better utilized within their organizations by automating routine
> tasks
> >> >related to endpoint and server security so that practitioners can
> >> focus
> >> >on more advanced tasks. The initial focus of this work is to
> address
> >> >enterprise use cases.
> >> >
> >> >The working group will achieve this by enabling the exchange of
> shared
> >> >intelligence and continuing the security automation work already
> >> >performed by various organizations around the world.  The initial
> work
> >> >has been fruitful, and the data formats previously published are
> ready
> >> >for expansion on the international stage. Of particular interest
> >> >to this working group are the security automation specifications
> >> >supporting asset, change, configuration, and vulnerability
> management.
> >> >
> >> >By undertaking this work, we recognize that there are multiple
> >> >categories of problems in the security automation domain: enabling
> >> >interoperable data exchanges through standardized protocols,
> defining
> >> >expressions for particular domain concepts (i.e. data formats),
> >> >establishing a standards-based foundation supporting the curation
> and
> >> >exchange of security automation content collections in content
> >> >repositories, and enabling interoperability through the
> >> >development
> >> and
> >> >use of standard interfaces and communications protocols. Content
> based
> >> >on rich data standards and protocols will provide the
> >> >authoritative instructions needed by data-driven tools to enable
> >> >the automated collection and exchange of configuration and
> >> >vulnerability data pertaining to enterprise assets. Information
> >> >produced by these
> tools
> >> >will provide accurate and timely situational awareness in support
> of
> >> >organizational decision making.
> >> >
> >> >The data exchange protocols will need to meet several exchange
> types
> >> >including requesting assessments and reporting on assessment
> results.
> >> >Exchanging information across organizational boundaries will not
> >> >be within scope for this effort at this time.
> >> >
> >> >This working group will provide solutions to these categories of
> >> >problems and the main areas of focus for this working group are
> >> >described as follows:
> >> >
> >> >1. Define, either by normative reference, adoption, or creation, a
> set
> >> >of standards to enable security assessment of computing systems.
> >> >This area of focus provides for necessary language and data format
> >> >specifications.
> >> >
> >> >2. Define, either by normative reference, adoption, or creation, a
> set
> >> >of standards for interacting with repositories of content related
> to
> >> >security assessment of computing systems.
> >> >
> >> >This working group will achieve the following milestones:
> >> >
> >> >- An Informational document on Use Cases and Requirements
> >> >- An Informational document on SACM Architecture
> >> >- A Standards Track document to define a protocol for interacting
> >> >  with content repositories
> >> >- Standards Track documents specifying communication protocols and
> >> >  data formats used for security assessment of systems
> >> >- A Standards Track document specifying asset description format
> >> >- A Standards Track document specifying asset identification
> >> >[- A Standards Track document specifying platform naming
> >> >- A Standards Track document specifying platform matching
> >> >- A Standards Track document specifying platform applicability]
> >> >
> >> >After this work is completed, complementary deliverables may be
> >> >defined.
> >> >
> >>
> >>
> >> _______________________________________________
> >> sacm mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/sacm
> >
> >
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

---

From: "Allan Thomson (althomso)" <[email-masked]>
Date: Thu, 24 Jan 2013 04:44:47 +0000

David - thanks for sending out the references.

Its interesting that the endpoint examples listed below and in RFC5209 do
not include network infrastructure devices like switches, routers...etc. But
the text describes "anything that can have an IP address" which would be
inclusive of all devices.

So it would seem this group wants to use the definition of an endpoint to
be inclusive of network infrastructure devices? Is that correct?

It might help clarify the charter if we don't just reference the NEA RFC
but explicitly state that assessment is inclusive of all IP assigned
devices including the network infrastructure itself.

allan

On 1/23/13 3:50 AM, "Waltermire, David A." <[email-masked]>
wrote:

>I stubbed out a glossary section for the Use Cases document, but didn't
>include it in the most recent draft since I didn't have any associated
>definitions.  There is a mixture of terminology used within the draft.
>It would be useful to tighten down the terms used to a smaller set.  The
>following terms/definitions would go a long way to addressing this and
>would also set us up to talk more succinctly relative to the use case and
>architecture documents.
>
>* Asset - ISO/IEC 27001:2005 defines an asset as: "Any tangible or
>intangible thing that has value to an organization."
>
>Short and sweet.  Got this off a web reference.  I don't have a copy of
>the doc right now.  I'll double check it tomorrow.
>
>We use a similar definition at NIST in NISTIR 7693 section 2.1
>(http://csrc.nist.gov/publications/nistir/ir7693/NISTIR-7693.pdf):
>"Anything that has value to an organization, including, but not limited
>to, another organization, person, computing device, information
>technology (IT) system, IT network, IT circuit, software (both an
>installed instance and a physical instance), virtual computing platform
>(common in cloud and virtualized computing), and related hardware (e.g.,
>locks, cabinets, keyboards)."
>
>Also from SP 800-30r1
>(http://csrc.nist.gov/publications/nistpubs/800-30-rev1/sp800_30_r1.pdf)
>relative to "organizational assets": "The term organizational assets can
>have a very wide scope of applicability to include, for example,
>high-impact programs, physical plant, mission-critical information
>systems, personnel, equipment, or a logically related group of systems.
>More broadly, organizational assets represent any resource or set of
>resources which the organization values, including intangible assets such
>as image or reputation.
>
>* Endpoint - Reference RFC 5209 section 2
>(http://tools.ietf.org/html/rfc5209#section-2) definition: "Any computing
>device that can be connected to a network. [snip] This includes: laptops,
>desktops, servers, cell phones, or any device that may have an IP
>address."
>
>* Posture - Reference RFC 5209 section 2
>(http://tools.ietf.org/html/rfc5209#section-2) definition:
>"Configuration and/or status of hardware or software on an endpoint as it
>pertains to an organization's security policy".
>
>* Assessment - Reference RFC 5209 section 2
>(http://tools.ietf.org/html/rfc5209#section-2) definition:  "The process
>of collecting posture for a set of capabilities on the endpoint (e.g.,
>host-based firewall) such that the appropriate validators may evaluate
>the posture against compliance policy."
>
>Not sure this exactly maps to our use of "assessment", since compliance
>validation is only one possible use of collected information.  It doesn't
>address other uses for situational awareness over endpoints such as
>vulnerability detection, license management, etc.  The term
>"capabilities" might map to software or software components in our case.
>
>* Attribute - Reference RFC 5209 section 2
>(http://tools.ietf.org/html/rfc5209#section-2) definition:  "Data element
>including any requisite meta-data describing  an observed, expected, or
>the operational status of an endpoint  feature (e.g., anti-virus software
>is currently in use)."
>
>* Posture Attributes - Reference RFC 5209 section 2
>(http://tools.ietf.org/html/rfc5209#section-2) definition:  "Attributes
>describing the configuration or status (posture) of a feature of the
>endpoint.  For example, a Posture Attribute might describe the version of
>the operating system installed on the system."
>
>This can be used to represent a specific assertion about endpoint state
>(e.g. configuration setting, installed software, etc.)  Also assumes that
>installed software or software components are a "feature of the endpoint".
>
>RFC 5209 defines an endpoint as "Any computing device that can be
>connected to a network." It further states "This includes: laptops,
>desktops, servers, cell phones, or any device that may have an IP
>address." So I think that a router, switch, firewall, or wireless access
>point would be included. These days, a VOIP phone, thermostat, printer,
>automobile, or household appliance might well also fall into this
>category. And that's a good thing.
>We don't need to invent different protocols for assessing the security
>posture of a printer vs. a laptop vs. a router. The NEA protocols were
>designed to be flexible enough to accommodate the particular needs of
>different kinds of devices. For example, the IEEE Printer WG is defining
>for printer-specific attributes that are designed to go into the NEA
>protocols. See these docs:
>
>Similarly, "posture" is defined in IETF RFC 5209 as "Configuration and/or
>status of hardware or software on an endpoint as it pertains to an
>organization's security policy".
>
>Given the broad definition of endpoint earlier in that document (which is
>an IETF RFC) and the use of these same terms across the NEA standards
>(like RFC 5792 and RFC 5793), I think we have well-established words for
>the devices/endpoints/thingies whose security
>configuration/posture/whatever we are assessing. I'm sure that there are
>many words for the same concept across all the different communities of
>interest. VOIP phone manufacturers and standards groups probably use a
>different term than printer manufacturers or auto manufacturers or
>appliance manufacturers.
>Since the terms "endpoint" and "posture" are used in the NEA standards
>and those are IETF Standards-track RFCs that we'll probably be reusing
>and building on in SACM, I suggest that we use the same terms in SACM.
>
>And once we settle this wording issue, I totally agree that the charter
>should be clarified to explicitly state that we're focused on posture
>assessment of endpoints. Assuming, that is, that there is rough consensus
>on this on the list.
>
>Thanks,
>
>Steve
>

---

From: Stephen Hanna <[email-masked]>
Date: Thu, 24 Jan 2013 14:56:28 +0000

I think we have agreement that everything with an IP address
should be included as an endpoint in our definition and
therefore within scope for posture assessment with SACM.

Network infrastructure devices such as routers and switches
and firewalls should certainly be included. Ensuring that
they are secure is arguably more important than keeping
a user's laptop or tablet secure. If anyone disagrees,
they should speak up now and explain why. Since nobody
has disagreed so far and we've been discussing this for
a few days, I think we can assume that there's consensus
that posture assessment of network infrastructure devices
should be within scope for this effort.

Now we can move on to the question of where we should
say this explicitly. RFC 5209 includes a pretty good
definition of Endpoint:

   Endpoint - Any computing device that can be connected to a network.
      Such devices normally are associated with a particular link layer
      address before joining the network and potentially an IP address
      once on the network.  This includes: laptops, desktops, servers,
      cell phones, or any device that may have an IP address.

As Allan points out, this definition includes network
infrastructure devices since they have IP addresses
but it doesn't EXPLICITLY mention them. Some people
might think that they're not included for some reason.
Maybe because they have preconceptions about what the
term "endpoint" means. For that matter, some people
might think that we don't mean to include thermostats
or video cameras or SCADA and ICS systems like the
PLC for a pump in a chemical plant.

We could add a bunch of examples and I'm fine with
doing so in the glossary of the Use Cases document.
I'm not so keen on adding that list to the charter
because it's too long already. But if people believe
that it's important to explicitly point out in the
charter that Endpoint includes network infrastructure,
I'm OK with doing so. I certainly can see how there
might be a lot of people at IETF who would care more
about our effort if they knew that this was in scope.

Thanks,

Steve

> From: Michael Hammer [mailto:[email-masked]]
> Sent: Thursday, January 24, 2013 9:15 AM
> To: [email-masked]; [email-masked]; Stephen Hanna;
> [email-masked]
> Subject: RE: [sacm] Terms and Definitions (was RE: SACM Charter
> Focused)
> 
> With the SDN efforts on-going, the distinction between endpoints and
> network
> could further blur.
> 
> Mike
> 
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Allan Thomson (althomso)
> Sent: Wednesday, January 23, 2013 11:45 PM
> To: Waltermire, David A.; Stephen Hanna; [email-masked]'
> Subject: Re: [sacm] Terms and Definitions (was RE: SACM Charter
> Focused)
> 
> So it would seem this group wants to use the definition of an endpoint
> to be
> inclusive of network infrastructure devices? Is that correct?
> 
> It might help clarify the charter if we don't just reference the NEA
> RFC but
> explicitly state that assessment is inclusive of all IP assigned
> devices
> including the network infrastructure itself.
> 
> allan
> 
> >It would be useful to tighten down the terms used to a smaller set.
> >The following terms/definitions would go a long way to addressing this
> >and would also set us up to talk more succinctly relative to the use
> >case and architecture documents.
> >
> >(common in cloud and virtualized computing), and related hardware
> >(e.g., locks, cabinets, keyboards)."
> >
> >Also from SP 800-30r1
> >(http://csrc.nist.gov/publications/nistpubs/800-30-
> rev1/sp800_30_r1.pdf
> >) relative to "organizational assets": "The term organizational assets
> >can have a very wide scope of applicability to include, for example,
> >resources which the organization values, including intangible assets
> >such as image or reputation.
> >
> >(http://tools.ietf.org/html/rfc5209#section-2) definition: "Any
> >computing device that can be connected to a network. [snip] This
> >includes: laptops, desktops, servers, cell phones, or any device that
> >may have an IP address."
> >
> >"Configuration and/or status of hardware or software on an endpoint as
> >it pertains to an organization's security policy".
> >
> >(http://tools.ietf.org/html/rfc5209#section-2) definition:  "The
> >process of collecting posture for a set of capabilities on the
> endpoint
> >(e.g., host-based firewall) such that the appropriate validators may
> >evaluate the posture against compliance policy."
> >
> >validation is only one possible use of collected information.  It
> >doesn't address other uses for situational awareness over endpoints
> >such as vulnerability detection, license management, etc.  The term
> >(http://tools.ietf.org/html/rfc5209#section-2) definition:  "Data
> >element including any requisite meta-data describing  an observed,
> >expected, or the operational status of an endpoint  feature (e.g.,
> >anti-virus software is currently in use)."
> >
> "Attributes
> >endpoint.  For example, a Posture Attribute might describe the version
> >of the operating system installed on the system."
> >
> >(e.g. configuration setting, installed software, etc.)  Also assumes
> >that installed software or software components are a "feature of the
> endpoint".
> >
> >address." So I think that a router, switch, firewall, or wireless
> >access point would be included. These days, a VOIP phone, thermostat,
> >printer, automobile, or household appliance might well also fall into
> >this category. And that's a good thing.
> >different kinds of devices. For example, the IEEE Printer WG is
> >defining for printer-specific attributes that are designed to go into
> >the NEA protocols. See these docs:
> >
> >Similarly, "posture" is defined in IETF RFC 5209 as "Configuration
> >and/or status of hardware or software on an endpoint as it pertains to
> >an organization's security policy".
> >
> >Given the broad definition of endpoint earlier in that document (which
> >is an IETF RFC) and the use of these same terms across the NEA
> >standards (like RFC 5792 and RFC 5793), I think we have
> >well-established words for the devices/endpoints/thingies whose
> >security configuration/posture/whatever we are assessing. I'm sure
> that
> >there are many words for the same concept across all the different
> >communities of interest. VOIP phone manufacturers and standards groups
> >probably use a different term than printer manufacturers or auto
> >manufacturers or appliance manufacturers.
> >But we should settle on a single term for each concept here in the
> SACM
> >community.
> >
> >assessment of endpoints. Assuming, that is, that there is rough
> >consensus on this on the list.
> >
> >Thanks,
> >
> >Steve
> >
> >> static/configuration/posture assessment represents. If there is a
> >> term that can be used equally for both categories of
> network/endpoint
> >> >The problem that I have with the term "Static" is that posture is
> >> >not static. It changes, as Dave pointed out.
> >> >An endpoint can get infected or have a new program installed on it
> >> >or have its configuration changed.
> >> >I would point out that there are many ways of determining posture.
> >> >If the endpoint supports the NEA protocols, you can use those to
> >> >can employ other techniques such as sending commands to the
> >> >endpoint, installing an agent on the endpoint, or even just
> >> >observing its traffic to see whether it's acting like a VOIP phone
> >> >or a Windows 7 system. I believe that we want to support all these
> >> >techniques in SACM. Do others agree? Disagree?
> >> >
> >> >Thanks,
> >> >
> >> >Steve
> >> >
> >> >> Hi - Apologize for the delay in reviewing the charter document
> >> >> that Steve sent out.
> >> >>
> >> >> I believe the intent of this group is only the
> >> >> Configuration/Static category I have described. Is that correct?
> >> >> If so, it would be
> >> helpful
> >> >> periodic basis based on fairly static configuration content, but
> >> >> it doesn't have to work this way.  Many operating systems and
> >> applications
> >> >> 2) "The working group will achieve this by enabling the exchange
> >> >> of shared Intelligence"
> >> >>
> >> >>         B) Multiple security vendors have the concept of
> >> >> reputation and/or blacklists and have protocols to distribute
> that
> >> >> information
> >> to
> >> >> - It would seem that this group is focused on assessing security
> >> >> of endpoints/servers where "intelligence" feeds may influence an
> >> >> assessment
> >> >> - Is intelligence gathering and distribution part of the charter
> >> >> at all?
> >> >>
> >> >> C) network/application configuration (such as router
> >> >> configuration, laptop network interface configuration, firewall
> >> >> settingsŠ.etc)
> >> >>
> >> >> systems being assessed to gather all of this information? Some
> >> >> that come to mind are things like latency, volume of data, data
> >> >> access control, authenticity of the data, number of systems
> >> >> expected in a single assessment domain (e.g.
> >> >> fault tolerance into any repository solution supporting
> >> >> federation, caching, and clustering concepts.]
> >> >>
> >> >> interoperability without mandating that all security information
> >> >> or assessment thereof has to be done utilizing a single content
> >> >> repository.
> >> >>
> >> >> [DAW: I agree.]
> >> >>
> >> >> My 10cents.
> >> >>
> >> >> Allan Thomson
> >> >>
> >> >>
> >> >>
> >> >> >     To Subscribe:
> http://www.ietf.org/mailman/listinfo/sacm
> >> >> >develop security automation protocols and data format standards
> >> >> >in support of information security processes and practices where
> >> >> >categories of problems in the security automation domain:
> >> >> >enabling interoperable data exchanges through standardized
> >> >> >protocols,
> >> defining
> >> >> >This area of focus provides for necessary language and data
> >> >> >format specifications.
> >> >> >

---

From: Dave Misell <[email-masked]>
Date: Sun, 27 Jan 2013 04:24:23 +0000

Stephen,
Re Endpoint,
Can we have IP Network addressable instead of IP address

Yours Faithfully,

Dave Misell MSc CISSP
SilentCircle  dsm
07710 380044
[email-masked]

---

From: Stephen Hanna <[email-masked]>
Date: Mon, 28 Jan 2013 02:49:55 +0000

Dave,

I believe that you're pointing out that we should include devices that
don't currently have an IP address but may have an IP address at some
later time or may be accessible through a device that has an IP address.
If that's your concern, don't worry. The NEA Working Group took care
of that. The actual definition of Endpoint in RFC 5209 is:

So as you can see, the basic definition is "Any computing device that
can be connected to a network." I believe that addresses your concern.

BTW, one of the common uses for the TNC/NEA protocols is to assess
devices when they connect to an 802.11 network but before they get
an IP address assigned to them. The outcome of this assessment may
determine which network the device is connected or even whether the
device is connected to any network at all. So there's clearly no
requirement for an endpoint to have an IP address at the time that
it is assessed.

Thanks,

Steve

> Dave Misell
> Sent: Saturday, January 26, 2013 11:24 PM
> To: Stephen Hanna
> Cc: [email-masked]; Michael Hammer; [email-masked];
> [email-masked]
> Subject: [sacm] everything
> 
> Stephen,
> Re Endpoint,
> >> Its interesting that the endpoint examples listed below and in
> RFC5209
> >> do
> >> the text describes "anything that can have an IP address" which
> would
> >> be
> >>> Short and sweet.  Got this off a web reference.  I don't have a
> copy
> >> of
> >>> This can be used to represent the state information that is
> collected
> >>> from the endpoint.
> >>>
> >>>>>>> 1. Define, either by normative reference, adoption, or
> creation,
> >>>>>>> a
> >>>> set
> >>>>>>> 2. Define, either by normative reference, adoption, or
> creation,
> >>>>>>> a
> >>>> set