Subject: [sacm] sacm Next Steps

From: Shawn Mullen <[email-masked]>
Date: Mon, 21 Jan 2013 15:41:18 -0700

David, I agree that CPE has some well thought-out technology which we 
should reuse.  We would be foolish to reinvent.   There also seems to be 
consensus that a global repository cannot scale and cannot be maintained.  

The architecture point or methodology I am advocating is that the endpoint 
identify itself (CPE Well Formed Name is a great)  but the wfn is not 
taken back to huge central or distributed repository to lookup detailed 
prescriptive configuration settings unique to the device endpoint.   These 
types of repository are difficult for customer to manage and complicates 
vendor delivery models.

Endpoints generally ship with integrated configurable security 
capabilities such as password requirements.   Let the end point itself 
implement the precise configuration setting and report back on its method. 

For example 

I am a:
 wfn:[part="a",vendor="IBM",product="Virtual I/O Server", 
version="2\.5\1",update="NA"] 
You asked me to:
 Set your minimum password length to 8. 
I did this by"
 chuser -password_min_length = 8 
The command returned: 
 Successful

This allows me to deliver everything integrated on the endpoint.  I do not 
have to populate a repository with the config details.  I don't have a 
install touch point in the repository.  There is no test with other vendor 
repository solutions,  New systems, updated system and new-improved 
security version seamlessly integrate in methodology. 

Shawn Mullen 

From:   [email-masked]
To:     [email-masked]
Date:   01/19/2013 09:09 AM
Subject:        sacm Digest, Vol 11, Issue 27
Sent by:        [email-masked]

----- Message from Tony Rutkowski <[email-masked]> on Sat, 19 Jan 2013 
07:52:34 -0500 -----
To:
"Waltermire, David A." <[email-masked]>
cc:
David Solin <[email-masked]>, "[email-masked]" <[email-masked]>
Subject:
Re: [sacm] sacm Next Steps

Dave,

You should be aware that 3GPP this past year
brought together the major hardware and software
vendors to examine a SWID like approach which
they rejected.  Instead they worked with the major
OS vendors to adopted a common signature approach
that does not require a massive set of global registries
which doesn't exactly scale.

Their alternative has been adopted by all the relevant 
3GPP committees and is included in Rel.11 of the 
GSM standard for global deployment.  I believe the
OMA has also adopted the same approach.  This 
was also discussed at the IT-SAC in November. 

You can also pull the spec off the 3GPP standards
site for free rather than paying out money to ISO. :-)

--t

On 2013-01-18 10:44 PM, Waltermire, David A. wrote:
I agree, although the solution we use doesn’t have to be CPE.  The ISO 
19770-2 Software ID tagging standard is a valid alternative.  It may be 
possible to build an applicability language around its use.  It is also 
possible to generate CPE Names from SWID tags so they both can co-exist. 
Here is a good explanation:
 
http://tagvault.org/Automating_CPE_name_creation
 
Attached is a set of slides I developed illustrating how the current 
applicability language can be extended to support SWID tags.  This 
approach would also enable any policy/asset attribute to be used as well. 
I’d appreciate any feedback.
 
Sincerely,
Dave

----- Message from Tony Rutkowski <[email-masked]> on Sat, 19 Jan 2013 
08:05:05 -0500 -----
To:
"Waltermire, David A." <[email-masked]>
cc:
Stephen Hanna <[email-masked]>, "Allan Thomson \(althomso\)" 
<[email-masked]>, "[email-masked]'" <[email-masked]>
Subject:
Re: [sacm] SACM Charter Focused

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

On 2013-01-18 10:19 PM, Waltermire, David A. wrote:
> 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].

----- Message from Gary Gapinski <[email-masked]> on Sat, 19 Jan 2013 
08:28:51 -0500 -----
To:
"[email-masked]" <[email-masked]>
cc:
David Solin <[email-masked]>, "Waltermire, David A." 
<[email-masked]>, "[email-masked]" <[email-masked]>
Subject:
Re: [sacm] sacm Next Steps

On 01/19/2013 07:52 AM, Tony Rutkowski wrote:
> Dave,
>
> You should be aware that 3GPP this past year
> brought together the major hardware and software
> vendors to examine a SWID like approach which
> they rejected.  Instead they worked with the major
> OS vendors to adopted a common signature approach
> that does not require a massive set of global registries
> which doesn't exactly scale.

I'm quite pleased to hear this. Mobile devices continue to displace the
ones having had previous SACM attention at an ever increasing pace, and
have been ill-served thus far by security automation.

It is appropriate for the creators of things to identify those things.

>
> Their alternative has been adopted by all the relevant
> 3GPP committees and is included in Rel.11 of the
> GSM standard for global deployment.  I believe the
> OMA has also adopted the same approach.  This
> was also discussed at the IT-SAC in November.
>
> You can also pull the spec off the 3GPP standards
> site for free rather than paying out money to ISO. :-)

Can you supply a hint (series) of where in those standards one should
look for this?

Regards,

Gary

----- Message from Stephen Hanna <[email-masked]> on Sat, 19 Jan 2013 
14:58:46 +0000 -----
To:
"Waltermire, David A." <[email-masked]>, "Allan Thomson 
(althomso)" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject:
Re: [sacm] SACM Charter Focused

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: "Waltermire, David A." <[email-masked]>
Date: Tue, 22 Jan 2013 11:12:33 -0500

I agree that a global repository of software naming data will not scale.  This is a nice thing about SWID compared to CPE, where SWID allows for certified tags curated by repositories and 3rd party tags provided by independent entities.  CPE requires a single central curated repository.

Setting the CPE/SWID discussion aside for the time being, I don’t believe that a product naming scheme is a sufficient endpoint identifier.  The best it could do is point to a specific release of a software product.  It doesn’t describe all of the different instances of that software release on a network.  For that we will need one or more device identifiers (e.g. hardware cert, software cert, identity/secret, MAC address, etc.) to associate installed software.  Furthermore, we will then need to associate configuration (and other) state with the installed software as appropriate.

Your example below is more oriented towards setting state vs. reading state (our current scope of focus).  In my opinion the solution we come up with should make possible in the future to do both.  Looking at the read side, I think we have three parts to the problem.

1)      How do we identify the states (attributes and values) of the endpoint relative to the associated software?

For example, Linux minimum password length requirement = 8.

This type of capability is required to support policy evaluation both on and (even more so) off the endpoint.  By returning the actual state value, we enable the data collected in a single assessment to be used by many different downstream use cases, such as change control, configuration management, compliance, reporting and enforcement activities.  In many implemented architectures today, it is common to publish this information to a CMDB or similar enterprise data repository for further processing/analysis.

MIBs, Yang modules, OVAL objects, SWID tags/tag ids are examples of how attributes can be defined.

2)      How do we describe one or more technical mechanisms that can be used to collect the attributes/values?  For example, call a command and parse the output, or parse a text file for a specific parameter/value.

In an ideal world, all software might be capable of self-asserting its state using the mechanism in #1.  It is unlikely that this will ever be achieved for all software.  To fill this gap we will need well-defined technical mechanisms that provide instructions on how to collect the state attributes we care about.  Additionally, it may also be possible that the software self-asserts its state using a well-defined technical mechanism.  In this case the technical  mechanism can be asserted along with the information in #1 to provide more context on how the data was collected.

3)      How do we evaluate the collected states vs what was expected for the endpoint?

Using the information reported by #1 and automatable organizational policies, we can determine the degree of compliance with different frameworks and drive enforcement actions based on the asserted values.  Although this is largely beyond UC1, we would be establishing the groundwork to support UCs 2 and 3.

Is there consensus that the endpoint needs to identify: itself, the software that is installed (e.g. OS, application, patch), and any state information as it pertains to the installed software as part of the SACM scope?

Is what is described above the right approach?  Does anyone have any concerns?

Sincerely,
Dave

From: [email-masked] [mailto:[email-masked]] On Behalf Of Shawn Mullen
Sent: Monday, January 21, 2013 5:41 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [sacm] sacm Next Steps

David, I agree that CPE has some well thought-out technology which we should reuse.  We would be foolish to reinvent.   There also seems to be consensus that a global repository cannot scale and cannot be maintained.

The architecture point or methodology I am advocating is that the endpoint identify itself (CPE Well Formed Name is a great)  but the wfn is not taken back to huge central or distributed repository to lookup detailed prescriptive configuration settings unique to the device endpoint.   These types of repository are difficult for customer to manage and complicates vendor delivery models.

Endpoints generally ship with integrated configurable security capabilities such as password requirements.   Let the end point itself implement the precise configuration setting and report back on its method.
For example

I am a:
 wfn:[part="a",vendor="IBM",product="Virtual I/O Server", version="2\.5\1",update="NA"]
You asked me to:
 Set your minimum password length to 8.
I did this by"
 chuser -password_min_length = 8
The command returned:
 Successful

This allows me to deliver everything integrated on the endpoint.  I do not have to populate a repository with the config details.  I don't have a install touch point in the repository.  There is no test with other vendor repository solutions,  New systems, updated system and new-improved security version seamlessly integrate in methodology.

Shawn Mullen

From:        [email-masked]<mailto:[email-masked]>
To:        [email-masked]<mailto:[email-masked]>
Date:        01/19/2013 09:09 AM
Subject:        sacm Digest, Vol 11, Issue 27
Sent by:        [email-masked]<mailto:[email-masked]>
________________________________

----- Message from Tony Rutkowski <[email-masked]<mailto:[email-masked]>> on Sat, 19 Jan 2013 07:52:34 -0500 -----
To:

"Waltermire, David A." <[email-masked]<mailto:[email-masked]>>

cc:

David Solin <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Subject:

Dave,

--t

On 2013-01-18 10:44 PM, Waltermire, David A. wrote:
I agree, although the solution we use doesn’t have to be CPE.  The ISO 19770-2 Software ID tagging standard is a valid alternative.  It may be possible to build an applicability language around its use.  It is also possible to generate CPE Names from SWID tags so they both can co-exist.  Here is a good explanation:

Attached is a set of slides I developed illustrating how the current applicability language can be extended to support SWID tags.  This approach would also enable any policy/asset attribute to be used as well.  I’d appreciate any feedback.

Sincerely,
Dave

----- Message from Tony Rutkowski <[email-masked]<mailto:[email-masked]>> on Sat, 19 Jan 2013 08:05:05 -0500 -----
To:

"Waltermire, David A." <[email-masked]<mailto:[email-masked]>>

cc:

Stephen Hanna <[email-masked]<mailto:[email-masked]>>, "Allan Thomson \(althomso\)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]'" <[email-masked]<mailto:[email-masked]>>

Subject:

Hi All,

--tony

On 2013-01-18 10:19 PM, Waltermire, David A. wrote:
> 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].

----- Message from Gary Gapinski <[email-masked]<mailto:[email-masked]>> on Sat, 19 Jan 2013 08:28:51 -0500 -----
To:

"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

cc:

David Solin <[email-masked]<mailto:[email-masked]>>, "Waltermire, David A." <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Subject:

Regards,

Gary

----- Message from Stephen Hanna <[email-masked]<mailto:[email-masked]>> on Sat, 19 Jan 2013 14:58:46 +0000 -----
To:

"Waltermire, David A." <[email-masked]<mailto:[email-masked]>>, "Allan Thomson (althomso)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]'" <[email-masked]<mailto:[email-masked]>>

Subject:

Thanks,

Steve

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of
> Allan Thomson (althomso)
> On 1/17/13 10:09 AM, "Stephen Hanna" <[email-masked]<mailto:[email-masked]>> wrote:
>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
sacm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sacm

---

From: Tim Keanini <[email-masked]>
Date: Tue, 22 Jan 2013 16:38:28 +0000

David, let me summarize as a way to understand what you are saying here:

The identifier will have two important tasks: 1) to globally identify the class and 2) to be able to globally identify the instance.
It is an option that #2 have a local scope but only if there is a hierarchical structure where 2a is globally structured so that 2b can be local (think global structures like BGP where 2a is the AS#)

On your points 1,2,3, my comments:
#1. Summary: The evidence/findings.
The most flexible thing here is to establish a metadata schema as a base that can be extensible.  Something meta to even MIB, OVAL, SWID where by the proper context could be given to the data for appropriate machine and human handling.  I would also like to see built in some authenticity at this level because I’m tired of it always being an afterthought.
#2.  Summary: The method by which the data was sensed/collected
I also think that if we are looking to present a method here, it is also the place to talk about provenance and entailment.
#3. Summary: The synthesis/analysis performed on data(#1) within the context of the collection (#2)  to produce information #3. Again, because we are speaking of multi-sensor type of applications where, it will be important to build into the modeling a way to compute entailment: how did we go about coming to this inference or assertion?  (its need to be able to show its work)

I’ve been quite but I am paying attention.
Great discussion and now is the time to have it.

--tk

Chief Research Officer, nCircle...blog: patterns.ncircle.com…mbl: 415.328.2722…twtr: @tkeanini

From: [email-masked] [mailto:[email-masked]] On Behalf Of Waltermire, David A.
Sent: Tuesday, January 22, 2013 10:13 AM
To: Shawn Mullen; [email-masked]
Subject: Re: [sacm] sacm Next Steps

Sincerely,
Dave

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Shawn Mullen
Sent: Monday, January 21, 2013 5:41 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [sacm] sacm Next Steps

I am a:

Shawn Mullen

cc:

Subject:

Dave,

--t

Sincerely,
Dave

cc:

Subject:

Hi All,

--tony

cc:

Subject:

Regards,

Gary

Subject:

Thanks,

Steve

---

From: David Solin <[email-masked]>
Date: Tue, 22 Jan 2013 11:15:07 -0600

There certainly needs to be a way to identify the endpoint, and what's 
on it, as you've described.  However, the endpoint should not need not 
self-identify in any special way; we should merely require it to be what 
it is!

That is, we should not have to rely on there being a particular file, or 
special function, or special process running on any endpoint in order to 
manage it.  This is the beauty of the current implementation of CPE OVAL 
referenced by XCCDF -- the signature of the referenced platform is 
included.  Of course we may also admit alternative means of determining 
a signature, we need only to explain how they should be identified and 
referenced.

Regards,
--David (Solin)

On 1/22/2013 10:12 AM, Waltermire, David A. wrote:
> Is there consensus that the endpoint needs to identify: itself, the 
> software that is installed (e.g. OS, application, patch), and any 
> state information as it pertains to the installed software as part of 
> the SACM scope?

-- 

jOVAL.org: SCAP Simplified.
Learn More <http://www.joval.org> | Features 
<http://www.joval.org/features/> | Download 
<http://www.joval.org/download/>

---

From: "Waltermire, David A." <[email-masked]>
Date: Tue, 22 Jan 2013 12:36:39 -0500

You captured more succinctly what I was suggesting.  Good points.  In my mind provenance and entailment are crucial aspects to making this information useful.  Relative to provenance, we also need to capture identity and other context information for the sensor as part of the exchange.  This can be used downstream to identify the visibility of (e.g. authentication level, scope of collection, etc.), confidence in, and other important aspects of the sensor.

Do you have any suggestions on handling finding authenticity?  Do you have any specific mechanisms in mind?

Sincerely,
Dave

From: Tim Keanini [mailto:[email-masked]]
Sent: Tuesday, January 22, 2013 11:38 AM
To: Waltermire, David A.; Shawn Mullen; [email-masked]
Subject: RE: [sacm] sacm Next Steps

--tk

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Waltermire, David A.
Sent: Tuesday, January 22, 2013 10:13 AM
To: Shawn Mullen; [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] sacm Next Steps

Sincerely,
Dave

I am a:

Shawn Mullen

cc:

Subject:

Dave,

--t

Sincerely,
Dave

cc:

Subject:

Hi All,

--tony

cc:

Subject:

Regards,

Gary

Subject:

Thanks,

Steve

---

From: Gunnar Engelbach <[email-masked]>
Date: Tue, 22 Jan 2013 12:51:43 -0500

Dave, Shawn, great points to bring up, but I think it might be a bit 
premature to get into this level of a discussion.  I'd rather start with 
what functionality the asset identifier is needed to provide within the 
scope of the WG, then move from there onto requirements.

As a starting point, this is what I consider the bare minimum of usages 
for the asset identifier:

U1) Determine what content can or must be run on the endpoint*.

U2) Determine how to collect and evaluate any particular test for that 
endpoint.

U3) Communicate, unambiguously and to the necessary level of detail**, 
the asset details between software components.

U4) Ability to present the asset identity information in a 
human-readable format.

In additional to the above usages, and any others that are determined 
necessary, I'd like to suggest a few constraints:

C1) The asset identifier should be able to be determined in an automated 
manner

C2) The asset identifier, as communicated between entities, should be 
held to a minimal size.

C3) The asset identifier should be able to represented by a simple 
unambiguous manner, such as a reference, so that its embedded use in 
places like applicability clauses for individual benchmark tests can be 
kept from making their usage unwieldy.

C4) [from Dave and TK] Must contain provenance and entailment information.

What else do y'all think needs to be added?

* "Can" and "must" are two important distinctions to me.  "Can" refers 
to all tests that could possibly be applied to an asset regardless of 
purpose, to include tests that are unique for that asset, whereas "must" 
refers to the collection of tests that have to be applied toward a 
specific purpose, such as regulatory (HIPAA or PCI compliance) or best 
practices (Oracle, Sharepoint).

** "Necessary level of detail" is a pretty ambiguous term.  We can 
probably come to a rough consensus for what is needed right now for the 
current WG focus, but limiting it to a specific and finite list ala CPE 
might be too limiting for future use.  The only way to really protect 
against this is to make it extensible.

On 1/22/2013 11:12 AM, Waltermire, David A. wrote:
> I agree that a global repository of software naming data will not
> scale.  This is a nice thing about SWID compared to CPE, where SWID
> allows for certified tags curated by repositories and 3^rd party tags
> provided by independent entities.  CPE requires a single central curated
> repository.
>
> Setting the CPE/SWID discussion aside for the time being, I don’t
> believe that a product naming scheme is a sufficient endpoint
> identifier.  The best it could do is point to a specific release of a
> software product.  It doesn’t describe all of the different instances of
> that software release on a network.  For that we will need one or more
> device identifiers (e.g. hardware cert, software cert, identity/secret,
> MAC address, etc.) to associate installed software.  Furthermore, we
> will then need to associate configuration (and other) state with the
> installed software as appropriate.
>
> Your example below is more oriented towards setting state vs. reading
> state (our current scope of focus).  In my opinion the solution we come
> up with should make possible in the future to do both.  Looking at the
> read side, I think we have three parts to the problem.
>
> 1)How do we identify the states (attributes and values) of the endpoint
> relative to the associated software?
>
> This type of capability is required to support policy evaluation both on
> and (even more so) off the endpoint.  By returning the actual state
> value, we enable the data collected in a single assessment to be used by
> many different downstream use cases, such as change control,
> configuration management, compliance, reporting and enforcement
> activities.  In many implemented architectures today, it is common to
> publish this information to a CMDB or similar enterprise data repository
> for further processing/analysis.
>
> 2)How do we describe one or more technical mechanisms that can be used
> to collect the attributes/values?  For example, call a command and parse
> the output, or parse a text file for a specific parameter/value.
>
> In an ideal world, all software might be capable of self-asserting its
> state using the mechanism in #1.  It is unlikely that this will ever be
> achieved for all software.  To fill this gap we will need well-defined
> technical mechanisms that provide instructions on how to collect the
> state attributes we care about.  Additionally, it may also be possible
> that the software self-asserts its state using a well-defined technical
> mechanism.  In this case the technical  mechanism can be asserted along
> with the information in #1 to provide more context on how the data was
> collected.
>
> 3)How do we evaluate the collected states vs what was expected for the
> endpoint?
>
> Using the information reported by #1 and automatable organizational
> policies, we can determine the degree of compliance with different
> frameworks and drive enforcement actions based on the asserted values.
> Although this is largely beyond UC1, we would be establishing the
> groundwork to support UCs 2 and 3.
>
> software that is installed (e.g. OS, application, patch), and any state
> information as it pertains to the installed software as part of the SACM
> scope?
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf
> Of *Shawn Mullen
> *Sent:* Monday, January 21, 2013 5:41 PM
> *To:* [email-masked]
> *Cc:* [email-masked]; [email-masked]
> *Subject:* [sacm] sacm Next Steps
>
> The architecture point or methodology I am advocating is that the
> endpoint identify itself (CPE Well Formed Name is a great)  but the wfn
> is not taken back to huge central or distributed repository to lookup
> detailed prescriptive configuration settings unique to the device
> endpoint.   These types of repository are difficult for customer to
> manage and complicates vendor delivery models.
>
> This allows me to deliver everything integrated on the endpoint.  I do
> not have to populate a repository with the config details.  I don't have
> a install touch point in the repository.  There is no test with other
> vendor repository solutions,  New systems, updated system and
> new-improved security version seamlessly integrate in methodology.
>
>
> Shawn Mullen
>
>
>
>
> From: [email-masked] <mailto:[email-masked]>
> To: [email-masked] <mailto:[email-masked]>
> Sent by: [email-masked] <mailto:[email-masked]>
>
> ------------------------------------------------------------------------
>
>
>
>
>
>
> ----- Message from Tony Rutkowski<[email-masked]
> <mailto:[email-masked]>> on Sat, 19Jan 2013 07:52:34 -0500-----
>
> *To:*
>
> 	
>
> *cc:*
> David Solin<[email-masked] <mailto:[email-masked]>>, "[email-masked]
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>
> *Subject:*
>
> 	
>
> I agree, although the solutionwe use doesn’t have to be CPE. The ISO
> 19770-2 Software ID taggingstandard is a valid alternative. It may be
> possible to build an applicabilitylanguage around its use. It is also
> possible to generate CPE Namesfrom SWID tags so they both can co-exist.
> Attached is a set of slidesI developed illustrating how the current
> applicability language can beextended to support SWID tags. This
> approach would also enable anypolicy/asset attribute to be used as well.
> ----- Message from Tony Rutkowski<[email-masked]
> <mailto:[email-masked]>> on Sat, 19Jan 2013 08:05:05 -0500-----
>
> *To:*
>
> 	
>
> *cc:*
> Stephen Hanna<[email-masked] <mailto:[email-masked]>>, "Allan
> Thomson \(althomso\)" <[email-masked] <mailto:[email-masked]>>,
> "[email-masked]'" <[email-masked] <mailto:[email-masked]>>
>
> *Subject:*
>
> 	
>
>>In general, I'd like to see us not reinvent new terminology. Thereare
> plenty of sources of internationally agreed upon terms that we canpull
> from (e.g. ISO). We should look to use such terms as much aspossible.
> ----- Message from Gary Gapinski<[email-masked]
> <mailto:[email-masked]>> on Sat, 19 Jan2013 08:28:51 -0500 -----
>
> *To:*
>
> 	
>
> "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
>
> *cc:*
>
> 	
>
> David Solin<[email-masked] <mailto:[email-masked]>>, "Waltermire,
> David A." <[email-masked]
> <mailto:[email-masked]>>, "[email-masked]
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>
> *Subject:*
>
> 	
>
> ----- Message from Stephen Hanna<[email-masked]
> <mailto:[email-masked]>> on Sat, 19Jan 2013 14:58:46 +0000-----
>
> *To:*
>
> 	
>
> "Waltermire, David A." <[email-masked]
> <mailto:[email-masked]>>, "Allan Thomson (althomso)"
> <[email-masked] <mailto:[email-masked]>>, "[email-masked]'"
> <[email-masked] <mailto:[email-masked]>>
>
> *Subject:*
>
> 	
>
>>Posture - Configuration and/or status of hardware or softwareon an
>>endpoint as it pertains to an organization's securitypolicy.
>
>> -you assess a system's"security" by verifying compliancewith a
>> -typically is a direct communication with the system
>
> The problem that I have with the term"Static" is that
>>insightful. More comments inline. Does anyone else havea different
>>view?
>>
>>Dave
>>
>>In general, I'd like to see us not reinvent new terminology. Thereare
>>plenty of sources of internationally agreed upon terms that we canpull
>>from (e.g. ISO). We should look to use such terms as much aspossible.
>>From: [email-masked]
> <mailto:[email-masked]>[mailto:[email-masked]] On Behalf Of
>>Allan Thomson (althomso)
>> 1)Need a crisp definition of"Security assessment"
>>
>> -We need to clearly define what security aspects are being assessed
>> -There are at least 2 forms of assessing a system.
>>
>> [DAW: Do you know of an existing definition (preferred) or have agood
>>definition in mind?]
>>
>>A) Configuration/Static
>>B) Behavioral/Dynamic
>>
>>Static:
>> -you assess a system's"security" by verifying compliancewith a
>> -typically is a direct communication with the system
>>
>>Dynamic:
>> -you assess a system's"security" by assessing observed
>>network& security infrastructure devices with information onthe
>>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 awareof
>> [DAW: This is a great question. I believe we are focused (atleast
>>initially) on what you call the"static" aspects. Mostof our
>>discussions have been around standardizing how we assess the hostfor
>>software inventory, configuration and vulnerability concerns. Weare
>>information related to what you are calling"dynamic". Thiswill
>>enable implementations to correlate what the devices state is withhow
>>it is behaving on the network. This will help in detecting ifthe
>>device is lying to us about its state. This type of synthesisis where
>>continuous monitoring can become very powerful. To get therewe need
>>Assessment of configuration policy has traditionally be performedon a
>>concerns with such an approach. Doing this may also enable usto have
>> 2) "The working group will achieve this by enabling the exchangeof
>>shared Intelligence"
>>
>> -What specific intelligence are you referring to? There are other
>>forums and groups working on intelligence sharing and is it the goalof
>> -There are many examples but here are two that come to mind right
>>away:
>>A) IODEF/RID enables some level of sharingintelligence that
>>B) Multiple security vendors have theconcept of reputation
>>and/or blacklists and have protocols to distribute that informationto
>> -It would seem that this group is focused on assessing security of
>>endpoints/servers where"intelligence" feeds may influencean
>>assessment
>> -how that intelligence is gathered/authorized for access...etc isvery
>> -Please clarify the term intelligence and its use in the charter.
>> -Is it to distribute intelligence information from multiple sourcesto
>> -Is intelligence gathering and distribution part of the charter at
>>all?
>>
>>If we get to addressing UC2, Enforcement of Acceptable State, we maybe
>>able to use countermeasures provided by intelligence capabilitiesto
>> 3)It may be helpful to the charter to define what is actually being
>> -Similar to 1) above the configuration has many aspects including:
>>If so, what requirements have been defined and must be establishedfor
>> 100s-> 100ks?), version control of assessment protocols Š.etcto
>>ensure large environment can be assessed even when multiple versionsof
>>the"assessment protocol" are deployed
>>
>> [DAW: I believe all of these assessment types are in-scope. Asfar as
>>scale, this is something that we will need to address. As wework
>>feedback. If we are missing any of these requirements, pleaseraise
>>any concerns.]
>>
>> 4)The charter describes a"content repository" and a protocolto
>>access this repository
>>
>> -Given that there are likely multiple systems assessing different
>>different data domains. I also strongly believe that we needto build
>> -It may be better to think of the charter and protocols in termsof
>>If there are better"standard" terms for these entities/actorsshould
>>we adopt that taxonomy as the basis for the group's work? It wouldseem
>> [DAW: I am not sure I follow. There is a difference betweenthe
>>infrastructure components that support various roles/processes andthe
>>roles/processes themselves. In my opinion we are defining theI/O for
>> 5)Enabling vendors (networking; security; server; applications,
>>combinations
>>technologies. The idea that a single assessor will be created thatis
>>all knowledgeable about all aspects of technology in the environmentis
>>technologies (applications, configurations, networksŠ.etc) that mustbe
>>is NO single system doing that. There *may* be one but today thereare
>>multiple and likely that will continue for good technology reasonsand
>>business reasons.
>>
>> >*Added two deliverables: a SACM Architecture document and
>> >*Changed our areas of focus to be system security assessment
>> >*Removed the exchange of information across organizational
>> >boundaries
>> >
>> >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:
>> >Securing information and the systems that store, process, andtransmit
>> >that information has become a challenging task for organizationsof
>>all
>> >prioritize risk based on increased situational awareness fromshared
>> >intelligence is the key to escaping this rut. This working groupwill
>> >develop security automation protocols and data format standardsin
>> >practical. These standards will help security practitioners tobe
>> >better utilized within their organizations by automating routinetasks
>> >related to endpoint and server security so that practitionerscan
>>focus
>> >The working group will achieve this by enabling the exchange ofshared
>> >performed by various organizations around the world. Theinitial work
>> >has been fruitful, and the data formats previously published areready
>> >for expansion on the international stage. Of particular interestto
>> >establishing a standards-based foundation supporting the curationand
>> >use of standard interfaces and communications protocols. Contentbased
>> >pertaining to enterprise assets. Information produced by thesetools
>> >will provide accurate and timely situational awareness in supportof
>> >The data exchange protocols will need to meet several exchangetypes
>> >Exchanging information across organizational boundaries will notbe
>> >This working group will provide solutions to these categoriesof
>> >1.Define, either by normative reference, adoption, or creation, a set
>> >2.Define, either by normative reference, adoption, or creation, a set
>> >of standards for interacting with repositories of content relatedto
>> >-An Informational document on Use Cases and Requirements
>> >-An Informational document on SACM Architecture
>> >-A Standards Track document to define a protocol for interacting
>> >-Standards Track documents specifying communication protocolsand
>> >-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]
>> >
>>[email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>