Subject: Re: [sacm] SACM Charter Focused

From: "Allan Thomson (althomso)" <[email-masked]>
Date: Fri, 18 Jan 2013 16:09:47 +0000

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.

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.

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?

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

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

- 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.

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.

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.
>

---

From: Gunnar Engelbach <[email-masked]>
Date: Fri, 18 Jan 2013 12:28:52 -0500

Allan,

I haven't seen anybody else respond to your points yet, which I think 
are great to bring up, so I'll jump in with my own current 
understanding.  It's a good opportunity to see how the group consensus 
is running.

As briefly as I can:

1) Static.  Dynamic is also important, but different enough that I don't 
think the initial work is expecting to cover it.

2) "Intelligence" would be asset information, the data needed to perform 
security audits for those assests, and the results of those audits.

3) That which can be automated, which is *potentially* all of the above. 
  Actual requirements are To Be Determined.

4) There's no assumption of a single repository.  For any domain (eg 
USGCB, HIPAA, Vendor, etc) there may be a top-most authoritative 
repository.  There may also be 0-many local repositories to deal with 
workload, disconnected networks, non-public information, etc.

5) Exactly so.  The ability to interchange data at various level of the 
architecture makes it more likely to achieve a complete solution without 
having to wait for it to be fully implemented by any particular vendor. 
  And if it shakes out that existing standards meet the requirements of 
the WG, then it may be that much of this can be implemented via current 
offerings.

On 1/18/2013 11:09 AM, Allan Thomson (althomso) wrote:
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: "Waltermire, David A." <[email-masked]>
Date: Fri, 18 Jan 2013 22:19:26 -0500

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.

- 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.

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 we work through improving the use case and architecture documents, it would be great if you keep us focused on these concerns.  If we are missing any of these requirements, I would appreciate your feedback.]

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:
>
>And look out for another email from me suggesting more simplifications 
>and clarifications to the charter.
>
>Thanks,
>
>Steve
>
>--------
>
>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 
>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.
>
>supporting asset, change, configuration, and vulnerability management.
>
>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.
>
>After this work is completed, complementary deliverables may be 
>defined.
>

---

From: "Waltermire, David A." <[email-masked]>
Date: Fri, 18 Jan 2013 22:34:50 -0500

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,

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

[DAW: Do you know of an existing definition (preferred) or have a good definition in mind?]

A) Configuration/Static
B) Behavioral/Dynamic

Static:

Dynamic:

[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.]

[DAW: I agree.]

My 10cents.

Allan Thomson

---

From: Tony Rutkowski <[email-masked]>
Date: Sat, 19 Jan 2013 08:05:05 -0500

Hi All,

It might also be useful to work with other standards
bodies who are pursuing almost identical work.  The
SACM work was discussed at some length over the past
two days at the annual ETSI security workshop which
is significantly focussed on the mobile communities.

3GPPSA3 has a SECAM subgroup that is almost identical
to the focus and work of SACM.  They also are developing
use cases and meeting next week.  There is a very active
SECAM list that is having dialogues similar to the SACM
list.  (The chance similarity of the acronyms is ironic)
They work closely with the CCRA and the GSMA
Security Group.  Since they are the largest and most
active of the global standards bodies and their specs
become mandatory for vendors and operators across
the global mobile infrastructures and services, they are
worth working with.  They also believe in running code
and freely available standards.

They indicated a willingness at their meeting this coming
week in reaching out to SACM.  It might be useful going
the other way.

--tony

---

From: Stephen Hanna <[email-masked]>
Date: Sat, 19 Jan 2013 14:58:46 +0000

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

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.

> - 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

> From: Waltermire, David A. [mailto:[email-masked]]
> Sent: Friday, January 18, 2013 10:35 PM
> To: Allan Thomson (althomso); Stephen Hanna; [email-masked]'
> 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
> 
> 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
> 
> network & security infrastructure devices with information on the
> system you are assessing
> - in many cases the system being assessed for security is not aware of
> the systems that are providing security telemetry to the assessing
> system
> 
> 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.
> 
> [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.]
> 
> - 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?
>         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.
> 
> [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.]
> 
> 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.
> 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.]
> 
> - Given that there are likely multiple systems assessing different
> aspects of security its not clear to me how a single content repository
> (even if
> [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.]
> 
> 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.]
> 
> 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.
> 
> all
> focus
> and

---

From: "Allan Thomson (althomso)" <[email-masked]>
Date: Mon, 21 Jan 2013 20:11:11 +0000

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

---

From: Stephen Hanna <[email-masked]>
Date: Mon, 21 Jan 2013 20:56:39 +0000

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

> Sent: Monday, January 21, 2013 3:11 PM
> To: Stephen Hanna; Waltermire, David A.; [email-masked]'
> >> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of
> >> Allan Thomson (althomso)
> >> [DAW: Do you know of an existing definition (preferred) or have a
> good
> >> definition in mind?]
> >>
> >> A) Configuration/Static
> >> B) Behavioral/Dynamic
> >>
> >> Static:
> >> Clarifying the expectations in the charter will help define the
> scope
> >> of the group's work.
> >>

---

From: Gunnar Engelbach <[email-masked]>
Date: Mon, 21 Jan 2013 16:21:01 -0500

I concur with the explicit focus on endpoint postures, as long as there 
is no wording that denies behavioral assessments, or any other 
assessment type, as a possible goal.

The actual terminology used is arbitrary, but I agree with the rationale 
Steve gives.

---

From: Stephen Hanna <[email-masked]>
Date: Wed, 23 Jan 2013 14:17:13 +0000

Tony,

I looked at the 3GPP SA3 work on SECAM. While I understand
that they are meeting this week to define their work more,
SECAM seems to be currently focused on evaluating security
assurance methodologies for network products. For example,
they're looking at Common Criteria evaluation of firewalls
as a way to assure their security.

While that's interesting and it does demonstrate one way
to improve system security, I think SACM is proposing a
more dynamic approach. With the SACM model, administrators
define policies about endpoint posture. Endpoints are then
assessed relative to these policies in an automated manner.
If an individual endpoint falls out of compliance, this
can be noted and a response delivered rapidly. For example,
an endpoint that's missing a patch can be directed to
install the patch or protected by installing a firewall
rule that prevents remote exploitation of a vulnerability
addressed by the patch.

In contrast, a Common Criteria approach to assuring
system security would involve intensive analysis of
product design and implementation, followed by the
issuance of a certificate for a particular product
model and version. This analysis and certification
process might take a year or more and cost hundreds
of thousands of US dollars. Therefore, it will only
be conducted rarely and only with products that an
important and well-funded customer regards as
essential to security.

Each approach has its own benefits and drawbacks
but they operate on a very different timescale
and use very different techniques.

I still think it will be useful to have the SACM
and SECAM efforts stay in touch and inform each
other of their work. But I don't think there's
any overlap in these efforts.

Please let us know how things develop at 3GPP SA3
this week. If the SECAM project changes course or
refines its course in such a way that it substantially
overlaps with SACM, we should know about that ASAP.
And if I have mischaracterized SECAM, please speak
up and correct my misconceptions. I'm only going
from a review of the SECAM documents. You have been
following the SECAM emails and probably in-person
discussions as well.

Thanks,

Steve

> From: Tony Rutkowski [mailto:[email-masked]]
> Sent: Saturday, January 19, 2013 8:05 AM
> To: Waltermire, David A.
> Cc: Allan Thomson (althomso); Stephen Hanna; [email-masked]'
> > 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].
> 
>

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 23 Jan 2013 09:55:02 -0500

Hi Steve,

Your assessment is spot on.  However, there are
currently many views...and a fair amount of subject
matter unfamiliarity. There are many in
the SECAM initiative who have voiced concerns similar
to yours.  IMHO, the legacy Common Criteria
approach is not appropriate for them, and a more
dynamic oneis the appropriate model.  The SACM use case
document is exactly what they need to be considering.
This underscores the value of collaboration.

Getting the massive global mobile infrastructure
on the right path here is worth the effort.

--tony

---

From: Stephen Hanna <[email-masked]>
Date: Wed, 23 Jan 2013 15:04:55 +0000

Great! Well, please keep us informed about the progress
of the SECAM initiative. There may be an opportunity for
collaboration here and we certainly wouldn't want to
end up reinventing the wheel and creating competing
standards. With your assistance, I'm sure that can
be avoided.

BTW, SECAM stands for "Study on Security Assurance
Methodology for 3GPP Network Products". I guess that
IETF isn't the only group with odd acronyms! ;-)

Take care,

Steve

> Sent: Wednesday, January 23, 2013 9:55 AM
> To: Stephen Hanna
> Cc: [email-masked]'
> Subject: Re: 3GPP SECAM and IETF SACM
> 
> Hi Steve,
>