Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA

From: Adam Montville <[email-masked]>
Date: Mon, 7 May 2012 21:43:14 +0000

Kent,

Thank you for sending this out.  I like many of the suggestions you have made, especially about sending presentations/documentation ahead of time and time boxing based on subject.  The more work we can get done, the more value these sessions have, and the better our justification for attending so we can help create safer computing environments.

I agree with your points about what is/is not included in the original list, but would also like to add something: SACM.  I haven't seen too much activity on the SACM list, and I know that some of the listed topic areas are under consideration (in one way or another) for the SACM effort.  If Bedford attendees represent a significant portion of what we expect to constitute the initial SACM community, I would like to see us take some time to discuss and evaluate that effort – especially as IETF 84 will be later that month.

Regards,

Adam

From: kent_landfield <[email-masked]<mailto:[email-masked]>>
Reply-To: kent_landfield <[email-masked]<mailto:[email-masked]>>
Date: Monday, May 7, 2012 1:22 PM
To: Multiple recipients of list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA

All,

I would like to discuss the format for the SCAP Developer Days that seems to be listed below.

I see this appears to follow a path we have discussed in the past as the way not to hold a Dev Days event.  We have been trying to get away from 'Death by Powerpoint' and back to the type of event we held years ago when we were highly productive.  In the past we had a topic to be discussed and a time box to work within.  That allowed us to have very active brainstorming sessions in a high bandwidth environment.

At past Summer events we have got into a pattern of lots of powerpoint, lots of status of the efforts and very little discussion about things that need active discussions.  We need to keep moving forward and making progress as an effort. We can get status from various places such as the lists, a presentation being sent out in advance, a webinar if it is felt there will be questions and answers from those that are new to the efforts.  We have a limited amount of time and all who are attending are investing a great deal of time and money to be there.  We should not  be spending a great deal of time reeducating everyone when we could be focused on advancing needed efforts.

The type of approach to a Dev Days event was discussed at the last Summer Dev Days.  I have seen the following work quite well in other efforts.

  1.  Presentations are sent out to the attendees and the lists a week in advance.
  2.  Status for any effort is limited to 30 minutes
  3.  Focused brainstorming time should be established for certain areas that need real work by the community
  4.  Efforts to be discussed should be based on needs of the security automation space to move existing efforts to completion.

For example:

Continuous monitoring is a major direction the efforts are becoming involved with. There are going to be things we need to do as a security automation community to be able to accomplish what is listed in the CAESARS FE.  There are interfaces that need to be worked and established.  That is one area that is not listed below.  CM will have a major impact on all of us in the next couple years and it is being ignored.  We can't keep trying to solve what has already been solved.  We need to address the needed interface development now. This is an effort that could take nearly a whole day by itself.

Operationally we have a real need to be able to deliver SCAP content internally within an organization. Today the SCAP vendors cannot share a single local site security policy (XCCDF + OVAL + CPE +…) without the site staff having to go to each of the individual products and figuring out how to inject that new or updated policy into that products delivery mechanisms.  That is limiting sites from wanting to buy multiple focused SCAP products since they are such a pain to manage from a content perspective.  It is easier to buy from one vendor that has a single means for distributing content than it is to deal with the management issues that having multiple SCAP products presents.  We need to have at least an entire 1/2 a day on the development of a Content Repository specification.

OCIL is a positive and a negative at the same time. It has real value that is being underutilized and under implemented because of the limitations of how it addresses uses in an enterprise environment.  People don't need security automation to do things on/for a single host.  They need security automation to focus on the enterprise issues that reduce their costs and improve their efficiencies.  OCIL is failing in the enterprise and we all understand that.  We need to address developing a definitive solution for incorporating OCIL into the enterprise and that means into the existing specifications. Scheduling and tracking are key to it's success.  We need to make that happen.  This too needs a focused brainstorming time box to discuss options.

I am really disappointed that Remediation is not on the list below…  Yes, last Summer Dev Days, the time spent on Remediation was wasted time but that does not mean we should ignore it and not try to make some real progress.  As far as I am concerned we need to reboot the remediation effort.  We cannot keep being the set of specifications / tools that act as the little boy crying "Wolf" in the night.  We need to be able to find and fix issues if we are going to really make a difference in organizational security postures.  But today we think it is too hard so we don't try ?  I think we need a couple hours to discuss the reboot of the effort even if that means minimizing work already done.

A focused discussion on enterprise reporting is also critically needed.  For the vendors here, we have all gone through the Cyberscope goat rope, delivering limited capabilities to specific data call requirements of the Federal Agencies.  The initial effort was a mess, did little more than prove it was possible and cause the vendor community a great deal of thrashing to put a kludgey 'solution' in place.  Reality is all our customers need roll up reporting and an infrastructure that supports it.  A data call should not be special to anyone other than the agencies responding. The tools should be able to select the types of data needed and deliver that on a scheduled basis automatically.    Enterprise Reporting pertains to commercial as well as Federal customers.  We need to focus some time on what that would look like using the ARF and ASR as the foundational pieces.  But there are missing pieces….  We need this discussed.

I would hope we can make this summer's SCAP Dev Days useful in advancing the security automation efforts by addressing some of the more critical issues our customers are facing now or will be facing in the very short term.  Status presentations are not interesting to those active in the efforts.  Let's try to do those before we get to Bedford so we can real make some progress while we are all in the same room.  This is always a big event for the 'consensus of the willing' that assemble and driven to see security automation make a difference.  Let's see if we can have an event that, when we all walk out the last day, we all feel that every minute was well spent and moves us forward.

Thanks.

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: <Boczenowski>, Steve <[email-masked]<mailto:[email-masked]>>
Reply-To: "OVAL Developer List (Closed Public Discussion)" <[email-masked]<mailto:[email-masked]>>
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA

Frank;

We hope to have the registration site up next week.  The event will be during the week of July 9 – starting Monday at 10:00 AM and ending on Friday at 12:00.

Meanwhile, we are working on the agenda and are currently considering this list of topics:

CCE
CPE/SWID
CEE
XCCDF
OVAL
ASR
Enterprise OCIL
CybOX/MAEC
Federated Content Repository Spec
Endpoint Reporting for Continuous Monitoring and Compliance (ERCC)
MILE
TAXII
IF-M for SCAP
IF-MAP
SCAP Releases
SCAP and IETF
NETCONF and SCAP

Steve

From: Frank Lindsay Acker [mailto:[email-masked]]
Sent: Tuesday, May 01, 2012 9:32 AM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA

Steve....

Has there been any additional information regarding this event?

Thanks,
Frank Acker
________________________________
From: Boczenowski, Steve [[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, March 20, 2012 16:38
To: [email-masked]<mailto:[email-masked]>
Subject: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA
Save the Date: week of July 9, 2012

This year’s MITRE-hosted Security Automation Developer Days event will be held during the week of July 9, 2012 at MITRE’s facility in Bedford, MA.

Details to follow.

Regards,
    Steve

______________________________________________
Stephen P. Boczenowski
      The MITRE Corporation
      Office: (781) 271-7682
      Cell: (978) 302-3849
     [email-masked]<mailto:[email-masked]>

To unsubscribe, send an email message to [email-masked]<mailto:[email-masked]> with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [email-masked]<mailto:[email-masked]>.
To unsubscribe, send an email message to [email-masked]<mailto:[email-masked]> with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [email-masked]<mailto:[email-masked]>.
To unsubscribe, send an email message to [email-masked]<mailto:[email-masked]> with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [email-masked]<mailto:[email-masked]>.

---

From: "Waltermire, David A." <[email-masked]>
Date: Tue, 8 May 2012 10:44:03 -0400

Mike,

What about having webinars in-place of the 30 minute briefs?

Regarding content management, we are building the prototype content repository for use in a production environment.  As an open source project, it will be free for use by anyone interested.  My thinking is that this project can bridge the gap until commercial solutions are available to augment it.  This is a similar path that was followed with DNS (bind) and HTTP (apache).  When it is ready for use, I am hoping to use it to host USGCB content.  You would be welcome to use it for your needs.

It is good that OCIL is moving forward.  This is an important piece of supporting risk management and aspects of continuous monitoring.  I would also like to see some discussion on OCIL at Developer Days.  With the proposals we will likely have a sense of what needs to be discussed and what we can achieve consensus on outside the meeting.

Remediation is a topic near and dear to my heart.  I too would like to see it move forward.

We just published the draft ASR specification for public comment.  This specification supports enterprise aggregate reporting which greatly reduces the data volumes needed verses detailed host-based reports. This specification has been designed as a more robust replacement for LASR.  It can be used in continuous monitoring applications to support aggregate data reporting needs (e.g. FISMA reporting,  CyberScope).

Here are the links:

http://csrc.nist.gov/publications/PubsDrafts.html
http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7848

The primary reason we have suggested waiting on XCCDF is not the internationalization issue. Many vendors have commented that they are still working on implementing the XCCDF 1.2.1 specification. We will be in a better place in a few months once more development around XCCDF has occurred.  As we consider changes to the SCAP stack to address OCIL and other issues, we will identify areas that need improvement in XCCDF.  These are good and necessary discussions to have now, but we have a good deal of work to do before we are ready to open up XCCDF.  My suggestion is to work on these related areas and then work up change proposals for XCCDF as needed.  By that time we should be ready to work on a new revision of XCCDF.

I am also looking forward to the discussions at the conference.  It has been too long.

Sincerely,
Dave

From: Kinney, Michael A [mailto:[email-masked]]
Sent: Tuesday, May 08, 2012 7:09 AM
To: SCAP-DEV
Cc: Waltermire, David A.
Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA

Kent,

It's good to read your thoughts, and a realistic actionable approach is indeed needed.  Since all the activity hasn't been on the lists a brief ½ hour recap may be in order to bring everyone up to speed since there has been a lot of activity on CPE/SWID, OCIl, MAEC/CybOX CEE and others.

We could write a content repository specification, but without someone willing to stand one up it will be as valuable as the CCSS specification is today.  I've been trying for two years to get my management to get a coordinated effort together for the DoD to stand up a repository, it is a tough problem and will require funding with a tail, I'm not sure a specification will solve that problem.

We (DoD) have been putting a lot of effort into OCIL over the last year trying to make it useful in an enterprise environment and will be posting our ideas to the list before developer days it should have already started, we need to get consensus and a vote on how the community wishes to proceed.

Remediation is stalled but I'm making every effort to get it kick started from our perspective. I hope to assist in getting the draft ERI finished this year.  We are writing some new STIG content and intend to used the draft CRE specification to insert CRE into the content so we (DoD) can do some automatic configuration fixes, part of a self healing network concept. It is just a start but the best we can do at this point.

Enterprise reporting is an interesting subject, since XML adds size to and content to roll up reporting, in any enterprise of size the problem gets greater, I look forward to your thoughts on that subject.

I am concerned that the internationalization efforts are detracting from efforts to meet use cases, we have some things we would like changed in XCCDF to support our OCIl use case and I have been told that I need to wait. I didn't think that a move to internationalization should impede efforts to move forward with use cases.

I look forward to talking with you at the conference.

v/r

Mike Kinney
Project Director
Computer Network Defense Research and Technology (CND R&T) Office
9800 Savage Road Ste 6767
Ft Meade, MD 20755-6767
Phone: 410-854-4422
NSTS: 968-8886
Fax 410-854-4681
[email-masked]<mailto:[email-masked]>

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Waltermire, David A.
Sent: Monday, May 07, 2012 7:09 PM
To: Multiple recipients of list
Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA

Kent,

I like what you are saying here.  We are also in support of this type of approach.  We would like to see some community discussion around what are the key areas/priorities that the community would like to see discussed at Dev Days.  Your topics below look like a good start. The SACM list might be a better venue than the OVAL list for this discussion.  For each area we should focus the discussion around developing objectives for each session.  The sessions can be time boxed based on what would be a reasonable amount of time to accomplish each objective.  For example if continuous monitoring is a priority and collectively it takes 3 days to work through all the objectives, I see no problem with that.  We can also keep a few sessions "on deck" if all the objectives are reached and we complete all the scheduled sessions early.

Thoughts?

Sincerely,

David Waltermire
SCAP Architect
National Institute of Standards and Technology
(301) 975-3390
[email-masked]<mailto:[email-masked]>

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, May 07, 2012 4:25 PM
To: SCAP-DEV
Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA

All,

Operationally we have a real need to be able to deliver SCAP content internally within an organization. Today the SCAP vendors cannot share a single local site security policy (XCCDF + OVAL + CPE +...) without the site staff having to go to each of the individual products and figuring out how to inject that new or updated policy into that products delivery mechanisms.  That is limiting sites from wanting to buy multiple focused SCAP products since they are such a pain to manage from a content perspective.  It is easier to buy from one vendor that has a single means for distributing content than it is to deal with the management issues that having multiple SCAP products presents.  We need to have at least an entire 1/2 a day on the development of a Content Repository specification.

I am really disappointed that Remediation is not on the list below...  Yes, last Summer Dev Days, the time spent on Remediation was wasted time but that does not mean we should ignore it and not try to make some real progress.  As far as I am concerned we need to reboot the remediation effort.  We cannot keep being the set of specifications / tools that act as the little boy crying "Wolf" in the night.  We need to be able to find and fix issues if we are going to really make a difference in organizational security postures.  But today we think it is too hard so we don't try ?  I think we need a couple hours to discuss the reboot of the effort even if that means minimizing work already done.

A focused discussion on enterprise reporting is also critically needed.  For the vendors here, we have all gone through the Cyberscope goat rope, delivering limited capabilities to specific data call requirements of the Federal Agencies.  The initial effort was a mess, did little more than prove it was possible and cause the vendor community a great deal of thrashing to put a kludgey 'solution' in place.  Reality is all our customers need roll up reporting and an infrastructure that supports it.  A data call should not be special to anyone other than the agencies responding. The tools should be able to select the types of data needed and deliver that on a scheduled basis automatically.    Enterprise Reporting pertains to commercial as well as Federal customers.  We need to focus some time on what that would look like using the ARF and ASR as the foundational pieces.  But there are missing pieces....  We need this discussed.

Thanks.

Kent Landfield

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

Frank;

We hope to have the registration site up next week.  The event will be during the week of July 9 - starting Monday at 10:00 AM and ending on Friday at 12:00.

CCE
CPE/SWID
CEE
XCCDF
OVAL
ASR
Enterprise OCIL
CybOX/MAEC

Steve

Steve....

Thanks,
Frank Acker

This year's MITRE-hosted Security Automation Developer Days event will be held during the week of July 9, 2012 at MITRE's facility in Bedford, MA.

Details to follow.

Regards,
    Steve

---

From: "Kinney, Michael A" <[email-masked]>
Date: Tue, 8 May 2012 12:34:18 -0400

Dave,

I have no problem with webinars, I do want to keep developer days actionable
and use it to make decisions, and vote and accomplish things good or bad.  I
do not want this to be an informational briefing conference.

Thanks for the links.

I still think that any specification for a repository is wishful thinking
until someone builds one and learns the lessons it will just be another
whitepaper spec.  I believe the DoD needs to incorporate a metadata
repository as part of it and other customizations that may not be useful for
everyone.

We need to talk more…

-Mike  

From: Waltermire, David A. [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 10:44 AM
To: Kinney, Michael A; SCAP-DEV; [email-masked]
Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days:
Summer 2012 at MITRE in Bedford, MA

Mike,

Regarding content management, we are building the prototype content
repository for use in a production environment.  As an open source project,
it will be free for use by anyone interested.  My thinking is that this
project can bridge the gap until commercial solutions are available to
augment it.  This is a similar path that was followed with DNS (bind) and
HTTP (apache).  When it is ready for use, I am hoping to use it to host
USGCB content.  You would be welcome to use it for your needs.

It is good that OCIL is moving forward.  This is an important piece of
supporting risk management and aspects of continuous monitoring.  I would
also like to see some discussion on OCIL at Developer Days.  With the
proposals we will likely have a sense of what needs to be discussed and what
we can achieve consensus on outside the meeting.

Remediation is a topic near and dear to my heart.  I too would like to see
it move forward.

We just published the draft ASR specification for public comment.  This
specification supports enterprise aggregate reporting which greatly reduces
the data volumes needed verses detailed host-based reports. This
specification has been designed as a more robust replacement for LASR.  It
can be used in continuous monitoring applications to support aggregate data
reporting needs (e.g. FISMA reporting,  CyberScope).

Here are the links:

The primary reason we have suggested waiting on XCCDF is not the
internationalization issue. Many vendors have commented that they are still
working on implementing the XCCDF 1.2.1 specification. We will be in a
better place in a few months once more development around XCCDF has
occurred.  As we consider changes to the SCAP stack to address OCIL and
other issues, we will identify areas that need improvement in XCCDF.  These
are good and necessary discussions to have now, but we have a good deal of
work to do before we are ready to open up XCCDF.  My suggestion is to work
on these related areas and then work up change proposals for XCCDF as
needed.  By that time we should be ready to work on a new revision of XCCDF.

I am also looking forward to the discussions at the conference.  It has been
too long.

Sincerely,

Dave

From: Kinney, Michael A [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2012 7:09 AM
To: SCAP-DEV
Cc: Waltermire, David A.
Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days:
Summer 2012 at MITRE in Bedford, MA

Kent,

It’s good to read your thoughts, and a realistic actionable approach is
indeed needed.  Since all the activity hasn’t been on the lists a brief ½
hour recap may be in order to bring everyone up to speed since there has
been a lot of activity on CPE/SWID, OCIl, MAEC/CybOX CEE and others.

We could write a content repository specification, but without someone
willing to stand one up it will be as valuable as the CCSS specification is
today.  I’ve been trying for two years to get my management to get a
coordinated effort together for the DoD to stand up a repository, it is a
tough problem and will require funding with a tail, I’m not sure a
specification will solve that problem.

We (DoD) have been putting a lot of effort into OCIL over the last year
trying to make it useful in an enterprise environment and will be posting
our ideas to the list before developer days it should have already started,
we need to get consensus and a vote on how the community wishes to proceed.

Remediation is stalled but I’m making every effort to get it kick started
from our perspective. I hope to assist in getting the draft ERI finished
this year.  We are writing some new STIG content and intend to used the
draft CRE specification to insert CRE into the content so we (DoD) can do
some automatic configuration fixes, part of a self healing network concept.
It is just a start but the best we can do at this point.

Enterprise reporting is an interesting subject, since XML adds size to and
content to roll up reporting, in any enterprise of size the problem gets
greater, I look forward to your thoughts on that subject.

I am concerned that the internationalization efforts are detracting from
efforts to meet use cases, we have some things we would like changed in
XCCDF to support our OCIl use case and I have been told that I need to wait.
I didn’t think that a move to internationalization should impede efforts to
move forward with use cases.

v/r

Mike Kinney

Project Director

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of Waltermire,
David A.
Sent: Monday, May 07, 2012 7:09 PM
To: Multiple recipients of list
Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days:
Summer 2012 at MITRE in Bedford, MA

Kent,

I like what you are saying here.  We are also in support of this type of
approach.  We would like to see some community discussion around what are
the key areas/priorities that the community would like to see discussed at
Dev Days.  Your topics below look like a good start. The SACM list might be
a better venue than the OVAL list for this discussion.  For each area we
should focus the discussion around developing objectives for each session.
The sessions can be time boxed based on what would be a reasonable amount of
time to accomplish each objective.  For example if continuous monitoring is
a priority and collectively it takes 3 days to work through all the
objectives, I see no problem with that.  We can also keep a few sessions “on
deck” if all the objectives are reached and we complete all the scheduled
sessions early.

Thoughts?

Sincerely,

David Waltermire

SCAP Architect

(301) 975-3390

[email-masked]

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, May 07, 2012 4:25 PM
To: SCAP-DEV
Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days:
Summer 2012 at MITRE in Bedford, MA

All,

I would like to discuss the format for the SCAP Developer Days that seems to
be listed below.

I see this appears to follow a path we have discussed in the past as the way
not to hold a Dev Days event.  We have been trying to get away from 'Death
by Powerpoint' and back to the type of event we held years ago when we were
highly productive.  In the past we had a topic to be discussed and a time
box to work within.  That allowed us to have very active brainstorming
sessions in a high bandwidth environment.

At past Summer events we have got into a pattern of lots of powerpoint, lots
of status of the efforts and very little discussion about things that need
active discussions.  We need to keep moving forward and making progress as
an effort. We can get status from various places such as the lists, a
presentation being sent out in advance, a webinar if it is felt there will
be questions and answers from those that are new to the efforts.  We have a
limited amount of time and all who are attending are investing a great deal
of time and money to be there.  We should not  be spending a great deal of
time reeducating everyone when we could be focused on advancing needed
efforts.

The type of approach to a Dev Days event was discussed at the last Summer
Dev Days.  I have seen the following work quite well in other efforts.

1.	Presentations are sent out to the attendees and the lists a week in
advance.
2.	Status for any effort is limited to 30 minutes
3.	Focused brainstorming time should be established for certain areas
that need real work by the community
4.	Efforts to be discussed should be based on needs of the security
automation space to move existing efforts to completion.

For example:

Continuous monitoring is a major direction the efforts are becoming involved
with. There are going to be things we need to do as a security automation
community to be able to accomplish what is listed in the CAESARS FE.  There
are interfaces that need to be worked and established.  That is one area
that is not listed below.  CM will have a major impact on all of us in the
next couple years and it is being ignored.  We can't keep trying to solve
what has already been solved.  We need to address the needed interface
development now. This is an effort that could take nearly a whole day by
itself.

Operationally we have a real need to be able to deliver SCAP content
internally within an organization. Today the SCAP vendors cannot share a
single local site security policy (XCCDF + OVAL + CPE +…) without the site
staff having to go to each of the individual products and figuring out how
to inject that new or updated policy into that products delivery mechanisms.
That is limiting sites from wanting to buy multiple focused SCAP products
since they are such a pain to manage from a content perspective.  It is
easier to buy from one vendor that has a single means for distributing
content than it is to deal with the management issues that having multiple
SCAP products presents.  We need to have at least an entire 1/2 a day on the
development of a Content Repository specification.

OCIL is a positive and a negative at the same time. It has real value that
is being underutilized and under implemented because of the limitations of
how it addresses uses in an enterprise environment.  People don't need
security automation to do things on/for a single host.  They need security
automation to focus on the enterprise issues that reduce their costs and
improve their efficiencies.  OCIL is failing in the enterprise and we all
understand that.  We need to address developing a definitive solution for
incorporating OCIL into the enterprise and that means into the existing
specifications. Scheduling and tracking are key to it's success.  We need to
make that happen.  This too needs a focused brainstorming time box to
discuss options.

I am really disappointed that Remediation is not on the list below…  Yes,
last Summer Dev Days, the time spent on Remediation was wasted time but that
does not mean we should ignore it and not try to make some real progress.
As far as I am concerned we need to reboot the remediation effort.  We
cannot keep being the set of specifications / tools that act as the little
boy crying "Wolf" in the night.  We need to be able to find and fix issues
if we are going to really make a difference in organizational security
postures.  But today we think it is too hard so we don't try ?  I think we
need a couple hours to discuss the reboot of the effort even if that means
minimizing work already done.

A focused discussion on enterprise reporting is also critically needed.  For
the vendors here, we have all gone through the Cyberscope goat rope,
delivering limited capabilities to specific data call requirements of the
Federal Agencies.  The initial effort was a mess, did little more than prove
it was possible and cause the vendor community a great deal of thrashing to
put a kludgey 'solution' in place.  Reality is all our customers need roll
up reporting and an infrastructure that supports it.  A data call should not
be special to anyone other than the agencies responding. The tools should be
able to select the types of data needed and deliver that on a scheduled
basis automatically.    Enterprise Reporting pertains to commercial as well
as Federal customers.  We need to focus some time on what that would look
like using the ARF and ASR as the foundational pieces.  But there are
missing pieces….  We need this discussed.

I would hope we can make this summer's SCAP Dev Days useful in advancing the
security automation efforts by addressing some of the more critical issues
our customers are facing now or will be facing in the very short term.
Status presentations are not interesting to those active in the efforts.
Let's try to do those before we get to Bedford so we can real make some
progress while we are all in the same room.  This is always a big event for
the 'consensus of the willing' that assemble and driven to see security
automation make a difference.  Let's see if we can have an event that, when
we all walk out the last day, we all feel that every minute was well spent
and moves us forward.

Thanks.

Kent Landfield

Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com <http://www.mcafee.com/> 

From: <Boczenowski>, Steve <[email-masked]>
Reply-To: "OVAL Developer List (Closed Public Discussion)"
<[email-masked]>
To: "[email-masked]"
<[email-masked]>
Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days:
Summer 2012 at MITRE in Bedford, MA

Frank;

We hope to have the registration site up next week.  The event will be
during the week of July 9 – starting Monday at 10:00 AM and ending on Friday
at 12:00.

Meanwhile, we are working on the agenda and are currently considering this
list of topics:

CCE

CPE/SWID

CEE

XCCDF

OVAL

ASR

Enterprise OCIL

CybOX/MAEC

MILE

TAXII

IF-M for SCAP

IF-MAP

SCAP Releases

SCAP and IETF

NETCONF and SCAP

Steve

From: Frank Lindsay Acker [mailto:[email-masked]] 
Sent: Tuesday, May 01, 2012 9:32 AM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days:
Summer 2012 at MITRE in Bedford, MA

Steve....

Thanks,
Frank Acker

  _____  

From: Boczenowski, Steve [[email-masked]]
Sent: Tuesday, March 20, 2012 16:38
To: [email-masked]
Subject: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer
2012 at MITRE in Bedford, MA

This year’s MITRE-hosted Security Automation Developer Days event will be
held during the week of July 9, 2012 at MITRE’s facility in Bedford, MA.

Details to follow.

Regards,

    Steve

Stephen P. Boczenowski

      The MITRE Corporation

      Office: (781) 271-7682

      Cell: (978) 302-3849

     [email-masked]

To unsubscribe, send an email message to [email-masked] with
SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have
difficulties, write to [email-masked]. 

To unsubscribe, send an email message to [email-masked] with
SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have
difficulties, write to [email-masked]. 

To unsubscribe, send an email message to [email-masked] with
SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have
difficulties, write to [email-masked].

---

From: <[email-masked]>
Date: Fri, 11 May 2012 11:35:38 -0500

Mike I love it when you tee something up like that…. ;-)  Thank you. ;)

Mike wrote:
I still think that any specification for a repository is wishful thinking until someone builds one and learns the lessons it will just be another whitepaper spec.  I believe the DoD needs to incorporate a metadata repository as part of it and other customizations that may not be useful for everyone.
We need to talk more…

If you are talking about a holistic, complete federated approach to a content repository, I some what agree.  If you are talking about an organizational repository, I totally disagree. But you knew I would. ;)

Here is how I see the problem.  There is an immediate need for SCAP and other related content to be served up inside an organization.  Today we have situation where the standards allow us to provide sites the capability to have a single SCAP implemented policy they call official for their environment. Yes this is a rather simplistic since there are things such as targeting specific platforms, specific operational use needs, but for now lets agree SCAP is a massive improvement over the proprietary situations of the past. While we have created this standard content so that sites can implement their local site security once and then assure they are measuring all appropriately targeted devices the same way, we have failed to support the operational needs of the sites.  We have a situation where no two vendors distribute content the same way.  This causes massive problems for the administration staff when they need to incorporate a new SCAP enabled product into their architecture.  They need to discover how the new product supports distributing SCAP content to it's various components.  If they have one product then they do this one and they are done.  If they have multiple products they will have to figure out how to minimize the impact by incorporating the update process for the new product into the existing SCAP security content processes. Now when the inevitable happens and the site staff needs to make a change to their security policy, they have to make the modifications to the benchmark or checks or both and then distribute those updates across their network.  For each SCAP enabled product they have in place, they have doubled, tripled or more the work needed to make those updates available.

There is another content repository problem and that is the Federated Content Distribution.  If you think global DNS you have a general frame of reference.  The guidance authors need to be able to publish content in an authoritative manner so their content is updated in a timely fashion.  This is a much harder problem to solve if there is no local organizational infrastructure to support it. ;)

So here is what I am thinking…  We should consider addressing these as two separate but integrated efforts.  I believe the Organizational Content Repository is the more critical piece that is actually easier to address.  The Federated Content Distribution should be a subsequent effort integrating / augmenting the Organizational repository specification.

Mike, to your point that we need someone to build one first… That has happened already.  I have one as do other vendors but what we don’t have is the access specification.  Ours are focused on our specific product needs.  Additionally there is a company that has developed a commercial SCAP content repository that will be announced later this month. I won't steal their thunder but I was recently given a sneak peek at it and I must admit I was very impressed.  Again, to your point, it has been done. What is needed to address the initial operational problem is to develop a specification that provides a consistent means for all SCAP products to retrieve the appropriate content as configured and managed but the site.

TO THAT END….

I am requesting participation from those in the community that see the need and want to put in the work to make this specification happen.  I have talked to a couple of you but I do not want to assume your participation.  If you are interested please contact me so we can get this started.

Thanks!

Kent Landfield

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

From: <Kinney>, Michael A <[email-masked]<mailto:[email-masked]>>
To: David Waltermire <[email-masked]<mailto:[email-masked]>>, SCAP-DEV <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA

Dave,
I have no problem with webinars, I do want to keep developer days actionable and use it to make decisions, and vote and accomplish things good or bad.  I do not want this to be an informational briefing conference.
Thanks for the links.

I still think that any specification for a repository is wishful thinking until someone builds one and learns the lessons it will just be another whitepaper spec.  I believe the DoD needs to incorporate a metadata repository as part of it and other customizations that may not be useful for everyone.
We need to talk more…

-Mike

From: Waltermire, David A. [mailto:[email-masked]]
Sent: Tuesday, May 08, 2012 10:44 AM
To: Kinney, Michael A; SCAP-DEV; [email-masked]<mailto:[email-masked]>
Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA

Mike,

Here are the links:

Sincerely,
Dave

Kent,

It’s good to read your thoughts, and a realistic actionable approach is indeed needed.  Since all the activity hasn’t been on the lists a brief 1Ž2 hour recap may be in order to bring everyone up to speed since there has been a lot of activity on CPE/SWID, OCIl, MAEC/CybOX CEE and others.

We could write a content repository specification, but without someone willing to stand one up it will be as valuable as the CCSS specification is today.  I’ve been trying for two years to get my management to get a coordinated effort together for the DoD to stand up a repository, it is a tough problem and will require funding with a tail, I’m not sure a specification will solve that problem.

Remediation is stalled but I’m making every effort to get it kick started from our perspective. I hope to assist in getting the draft ERI finished this year.  We are writing some new STIG content and intend to used the draft CRE specification to insert CRE into the content so we (DoD) can do some automatic configuration fixes, part of a self healing network concept. It is just a start but the best we can do at this point.

I am concerned that the internationalization efforts are detracting from efforts to meet use cases, we have some things we would like changed in XCCDF to support our OCIl use case and I have been told that I need to wait. I didn’t think that a move to internationalization should impede efforts to move forward with use cases.

v/r

Mike Kinney
Project Director

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Waltermire, David A.
Sent: Monday, May 07, 2012 7:09 PM
To: Multiple recipients of list
Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA

Kent,

I like what you are saying here.  We are also in support of this type of approach.  We would like to see some community discussion around what are the key areas/priorities that the community would like to see discussed at Dev Days.  Your topics below look like a good start. The SACM list might be a better venue than the OVAL list for this discussion.  For each area we should focus the discussion around developing objectives for each session.  The sessions can be time boxed based on what would be a reasonable amount of time to accomplish each objective.  For example if continuous monitoring is a priority and collectively it takes 3 days to work through all the objectives, I see no problem with that.  We can also keep a few sessions “on deck” if all the objectives are reached and we complete all the scheduled sessions early.

Thoughts?

Sincerely,

David Waltermire
SCAP Architect

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, May 07, 2012 4:25 PM
To: SCAP-DEV
Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA

All,

Thanks.

Kent Landfield

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

Frank;

CCE
CPE/SWID
CEE
XCCDF
OVAL
ASR
Enterprise OCIL
CybOX/MAEC

Steve

Steve....

Thanks,
Frank Acker

Details to follow.

Regards,
    Steve

---

From: Gunnar Engelbach <[email-masked]>
Date: Fri, 11 May 2012 12:42:56 -0400

I'm not going to make any other comments at this point other than noting 
that this is a worthwhile effort, so count me in.

--gun

ThreatGuard, Inc.

On 5/11/2012 12:35 PM, [email-masked] wrote:
> I still think that any specification for a repository is wishful
> thinking until someone builds one and learns the lessons it will just be
> another whitepaper spec. I believe the DoD needs to incorporate a
> metadata repository as part of it and other customizations that may not
> be useful for everyone.
>
> We need to talk more…
>
>
> If you are talking about a holistic, complete federated approach to a
> content repository, I some what agree. If you are talking about an
> organizational repository, I totally disagree. But you knew I would. ;)
>
>
> Here is how I see the problem. There is an immediate need for SCAP and
> other related content to be served up inside an organization. Today we
> have situation where the standards allow us to provide sites the
> capability to have a single SCAP implemented policy they call official
> for their environment. Yes this is a rather simplistic since there are
> things such as targeting specific platforms, specific operational use
> needs, but for now lets agree SCAP is a massive improvement over the
> proprietary situations of the past. While we have created this standard
> content so that sites can implement their local site security once and
> then assure they are measuring all appropriately targeted devices the
> same way, we have failed to support the operational needs of the sites.
> We have a situation where no two vendors distribute content the same
> way. This causes massive problems for the administration staff when they
> need to incorporate a new SCAP enabled product into their architecture.
> They need to discover how the new product supports distributing SCAP
> content to it's various components. If they have one product then they
> do this one and they are done. If they have multiple products they will
> have to figure out how to minimize the impact by incorporating the
> update process for the new product into the existing SCAP security
> content processes. Now when the inevitable happens and the site staff
> needs to make a change to their security policy, they have to make the
> modifications to the benchmark or checks or both and then distribute
> those updates across their network. For each SCAP enabled product they
> have in place, they have doubled, tripled or more the work needed to
> make those updates available.
>
>
> There is another content repository problem and that is the Federated
> Content Distribution. If you think global DNS you have a general frame
> of reference. The guidance authors need to be able to publish content in
> an authoritative manner so their content is updated in a timely fashion.
> This is a much harder problem to solve if there is no local
> organizational infrastructure to support it. ;)
>
>
> So here is what I am thinking… We should consider addressing these as
> two separate but integrated efforts. I believe the Organizational
> Content Repository is the more critical piece that is actually easier to
> address. The Federated Content Distribution should be a subsequent
> effort integrating / augmenting the Organizational repository
> specification.
>
>
> Mike, to your point that we need someone to build one first… That has
> happened already. I have one as do other vendors but what we don’t have
> is the access specification. Ours are focused on our specific product
> needs. Additionally there is a company that has developed a commercial
> SCAP content repository that will be announced later this month. I won't
> steal their thunder but I was recently given a sneak peek at it and I
> must admit I was very impressed. Again, to your point, it has been done.
> What is needed to address the initial operational problem is to develop
> a specification that provides a consistent means for all SCAP products
> to retrieve the appropriate content as configured and managed but the site.
>
>
> TO THAT END….
>
>
> I am requesting participation from those in the community that see the
> need and want to put in the work to make this specification happen. I
> have talked to a couple of you but I do not want to assume your
> participation. If you are interested please contact me so we can get
> this started.
>
>
> Thanks!
>
>
> *Kent Landfield*
> *McAfee | An Intel Company*
> 5000 Headquarters Dr.
> Plano, Texas 75024
>
> Direct: +1.972.963.7096
> Mobile: +1.817.637.8026
> *Web: *www.mcafee.com <http://www.mcafee.com/>
>
> To: David Waltermire <[email-masked]
> <mailto:[email-masked]>>, SCAP-DEV <[email-masked]
> <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>
> Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation Developer
> Days: Summer 2012 at MITRE in Bedford, MA
>
>     Dave,
>
>     I have no problem with webinars, I do want to keep developer days
>     actionable and use it to make decisions, and vote and accomplish
>     things good or bad. I do not want this to be an informational
>     briefing conference.
>
>     Thanks for the links.
>
>     I still think that any specification for a repository is wishful
>     thinking until someone builds one and learns the lessons it will
>     just be another whitepaper spec. I believe the DoD needs to
>     incorporate a metadata repository as part of it and other
>     customizations that may not be useful for everyone.
>
>     We need to talk more…
>
>     -Mike
>
>     *From:*Waltermire, David A. [mailto:[email-masked]]
>     *Sent:* Tuesday, May 08, 2012 10:44 AM
>     *To:* Kinney, Michael A; SCAP-DEV; [email-masked] <mailto:[email-masked]>
>     *Subject:* RE: [OVAL-DEVELOPER-LIST] Security Automation Developer
>     Days: Summer 2012 at MITRE in Bedford, MA
>
>     Mike,
>
>     repository for use in a production environment. As an open source
>     project, it will be free for use by anyone interested. My thinking
>     is that this project can bridge the gap until commercial solutions
>     are available to augment it. This is a similar path that was
>     followed with DNS (bind) and HTTP (apache). When it is ready for
>     use, I am hoping to use it to host USGCB content. You would be
>     welcome to use it for your needs.
>
>     It is good that OCIL is moving forward. This is an important piece
>     of supporting risk management and aspects of continuous monitoring.
>     I would also like to see some discussion on OCIL at Developer Days.
>     With the proposals we will likely have a sense of what needs to be
>     discussed and what we can achieve consensus on outside the meeting.
>
>     We just published the draft ASR specification for public comment.
>     This specification supports enterprise aggregate reporting which
>     greatly reduces the data volumes needed verses detailed host-based
>     reports. This specification has been designed as a more robust
>     replacement for LASR. It can be used in continuous monitoring
>     applications to support aggregate data reporting needs (e.g. FISMA
>     reporting, CyberScope).
>
>     Here are the links:
>
>     internationalization issue. Many vendors have commented that they
>     are still working on implementing the XCCDF 1.2.1 specification. We
>     will be in a better place in a few months once more development
>     around XCCDF has occurred. As we consider changes to the SCAP stack
>     to address OCIL and other issues, we will identify areas that need
>     improvement in XCCDF. These are good and necessary discussions to
>     have now, but we have a good deal of work to do before we are ready
>     to open up XCCDF. My suggestion is to work on these related areas
>     and then work up change proposals for XCCDF as needed. By that time
>     we should be ready to work on a new revision of XCCDF.
>
>     *From:*Kinney, Michael A [mailto:[email-masked]]
>     *Sent:* Tuesday, May 08, 2012 7:09 AM
>     *To:* SCAP-DEV
>     *Cc:* Waltermire, David A.
>     *Subject:* RE: [OVAL-DEVELOPER-LIST] Security Automation Developer
>     Days: Summer 2012 at MITRE in Bedford, MA
>
>     Kent,
>
>     It’s good to read your thoughts, and a realistic actionable approach
>     is indeed needed. Since all the activity hasn’t been on the lists a
>     brief 1Ž2 hour recap may be in order to bring everyone up to speed
>     since there has been a lot of activity on CPE/SWID, OCIl, MAEC/CybOX
>     CEE and others.
>
>     We could write a content repository specification, but without
>     someone willing to stand one up it will be as valuable as the CCSS
>     specification is today. I’ve been trying for two years to get my
>     management to get a coordinated effort together for the DoD to stand
>     up a repository, it is a tough problem and will require funding with
>     a tail, I’m not sure a specification will solve that problem.
>
>     We (DoD) have been putting a lot of effort into OCIL over the last
>     year trying to make it useful in an enterprise environment and will
>     be posting our ideas to the list before developer days it should
>     have already started, we need to get consensus and a vote on how the
>     community wishes to proceed.
>
>     Remediation is stalled but I’m making every effort to get it kick
>     started from our perspective. I hope to assist in getting the draft
>     ERI finished this year. We are writing some new STIG content and
>     intend to used the draft CRE specification to insert CRE into the
>     content so we (DoD) can do some automatic configuration fixes, part
>     of a self healing network concept. It is just a start but the best
>     we can do at this point.
>
>     Enterprise reporting is an interesting subject, since XML adds size
>     to and content to roll up reporting, in any enterprise of size the
>     problem gets greater, I look forward to your thoughts on that subject.
>
>     I am concerned that the internationalization efforts are detracting
>     from efforts to meet use cases, we have some things we would like
>     changed in XCCDF to support our OCIl use case and I have been told
>     that I need to wait. I didn’t think that a move to
>     internationalization should impede efforts to move forward with use
>     cases.
>
>     [email-masked] <mailto:[email-masked]>
>
>     *From:[email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked]] <mailto:[mailto:[email-masked]]> *On
>     Behalf Of *Waltermire, David A.
>     *Sent:* Monday, May 07, 2012 7:09 PM
>     *To:* Multiple recipients of list
>     *Subject:* RE: [OVAL-DEVELOPER-LIST] Security Automation Developer
>     Days: Summer 2012 at MITRE in Bedford, MA
>
>     Kent,
>
>     I like what you are saying here. We are also in support of this type
>     of approach. We would like to see some community discussion around
>     what are the key areas/priorities that the community would like to
>     see discussed at Dev Days. Your topics below look like a good start.
>     The SACM list might be a better venue than the OVAL list for this
>     discussion. For each area we should focus the discussion around
>     developing objectives for each session. The sessions can be time
>     boxed based on what would be a reasonable amount of time to
>     accomplish each objective. For example if continuous monitoring is a
>     priority and collectively it takes 3 days to work through all the
>     objectives, I see no problem with that. We can also keep a few
>     sessions “on deck” if all the objectives are reached and we complete
>     all the scheduled sessions early.
>
>     Thoughts?
>
>     Sincerely,
>
>     David Waltermire
>
>     SCAP Architect
>
>     [email-masked] <mailto:[email-masked]>
>
>     *From:[email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked]] <mailto:[mailto:[email-masked]]> *On
>     Behalf Of [email-masked] <mailto:[email-masked]>
>     *Sent:* Monday, May 07, 2012 4:25 PM
>     *To:* SCAP-DEV
>     *Subject:* Re: [OVAL-DEVELOPER-LIST] Security Automation Developer
>     Days: Summer 2012 at MITRE in Bedford, MA
>
>     All,
>
>     I see this appears to follow a path we have discussed in the past as
>     the way not to hold a Dev Days event. We have been trying to get
>     away from 'Death by Powerpoint' and back to the type of event we
>     held years ago when we were highly productive. In the past we had a
>     topic to be discussed and a time box to work within. That allowed us
>     to have very active brainstorming sessions in a high bandwidth
>     environment.
>
>     At past Summer events we have got into a pattern of lots of
>     powerpoint, lots of status of the efforts and very little discussion
>     about things that need active discussions. We need to keep moving
>     forward and making progress as an effort. We can get status from
>     various places such as the lists, a presentation being sent out in
>     advance, a webinar if it is felt there will be questions and answers
>     from those that are new to the efforts. We have a limited amount of
>     time and all who are attending are investing a great deal of time
>     and money to be there. We should not be spending a great deal of
>     time reeducating everyone when we could be focused on advancing
>     needed efforts.
>
>     The type of approach to a Dev Days event was discussed at the last
>     Summer Dev Days. I have seen the following work quite well in other
>     efforts.
>
>      3. Focused brainstorming time should be established for certain
>         areas that need real work by the community
>     Continuous monitoring is a major direction the efforts are becoming
>     involved with. There are going to be things we need to do as a
>     security automation community to be able to accomplish what is
>     listed in the CAESARS FE. There are interfaces that need to be
>     worked and established. That is one area that is not listed below.
>     CM will have a major impact on all of us in the next couple years
>     and it is being ignored. We can't keep trying to solve what has
>     already been solved. We need to address the needed interface
>     development now. This is an effort that could take nearly a whole
>     day by itself.
>
>     internally within an organization. Today the SCAP vendors cannot
>     share a single local site security policy (XCCDF + OVAL + CPE +…)
>     without the site staff having to go to each of the individual
>     products and figuring out how to inject that new or updated policy
>     into that products delivery mechanisms. That is limiting sites from
>     wanting to buy multiple focused SCAP products since they are such a
>     pain to manage from a content perspective. It is easier to buy from
>     one vendor that has a single means for distributing content than it
>     is to deal with the management issues that having multiple SCAP
>     products presents. We need to have at least an entire 1/2 a day on
>     the development of a Content Repository specification.
>
>     OCIL is a positive and a negative at the same time. It has real
>     value that is being underutilized and under implemented because of
>     the limitations of how it addresses uses in an enterprise
>     environment. People don't need security automation to do things
>     on/for a single host. They need security automation to focus on the
>     enterprise issues that reduce their costs and improve their
>     efficiencies. OCIL is failing in the enterprise and we all
>     understand that. We need to address developing a definitive solution
>     for incorporating OCIL into the enterprise and that means into the
>     existing specifications. Scheduling and tracking are key to it's
>     success. We need to make that happen. This too needs a focused
>     brainstorming time box to discuss options.
>
>     I am really disappointed that Remediation is not on the list below…
>     Yes, last Summer Dev Days, the time spent on Remediation was wasted
>     time but that does not mean we should ignore it and not try to make
>     some real progress. As far as I am concerned we need to reboot the
>     remediation effort. We cannot keep being the set of specifications /
>     tools that act as the little boy crying "Wolf" in the night. We need
>     to be able to find and fix issues if we are going to really make a
>     difference in organizational security postures. But today we think
>     it is too hard so we don't try ? I think we need a couple hours to
>     discuss the reboot of the effort even if that means minimizing work
>     already done.
>
>     A focused discussion on enterprise reporting is also critically
>     needed. For the vendors here, we have all gone through the
>     Cyberscope goat rope, delivering limited capabilities to specific
>     data call requirements of the Federal Agencies. The initial effort
>     was a mess, did little more than prove it was possible and cause the
>     vendor community a great deal of thrashing to put a kludgey
>     'solution' in place. Reality is all our customers need roll up
>     reporting and an infrastructure that supports it. A data call should
>     not be special to anyone other than the agencies responding. The
>     tools should be able to select the types of data needed and deliver
>     that on a scheduled basis automatically. Enterprise Reporting
>     pertains to commercial as well as Federal customers. We need to
>     focus some time on what that would look like using the ARF and ASR
>     as the foundational pieces. But there are missing pieces…. We need
>     this discussed.
>
>     I would hope we can make this summer's SCAP Dev Days useful in
>     advancing the security automation efforts by addressing some of the
>     more critical issues our customers are facing now or will be facing
>     in the very short term. Status presentations are not interesting to
>     those active in the efforts. Let's try to do those before we get to
>     Bedford so we can real make some progress while we are all in the
>     same room. This is always a big event for the 'consensus of the
>     willing' that assemble and driven to see security automation make a
>     difference. Let's see if we can have an event that, when we all walk
>     out the last day, we all feel that every minute was well spent and
>     moves us forward.
>
>     Thanks.
>
>     *Kent Landfield*
>     *McAfee | An Intel Company*
>     5000 Headquarters Dr.
>     Plano, Texas 75024
>
>     Direct: +1.972.963.7096
>     Mobile: +1.817.637.8026
>     *Web: *www.mcafee.com <http://www.mcafee.com/>
>
>     *From: *<Boczenowski>, Steve <[email-masked]
>     <mailto:[email-masked]>>
>     *Reply-To: *"OVAL Developer List (Closed Public Discussion)"
>     <[email-masked]
>     <mailto:[email-masked]>>
>     *To: *"[email-masked]
>     <mailto:[email-masked]>"
>     <[email-masked]
>     <mailto:[email-masked]>>
>     *Subject: *Re: [OVAL-DEVELOPER-LIST] Security Automation Developer
>     Days: Summer 2012 at MITRE in Bedford, MA
>
>         Frank;
>
>         We hope to have the registration site up next week. The event
>         will be during the week of July 9 – starting Monday at 10:00 AM
>         and ending on Friday at 12:00.
>
>         *From:*Frank Lindsay Acker [mailto:[email-masked]]
>         *Sent:* Tuesday, May 01, 2012 9:32 AM
>         *To:* oval-developer-list OVAL Developer List/Closed Public
>         Discussion
>         *Subject:* Re: [OVAL-DEVELOPER-LIST] Security Automation
>         Developer Days: Summer 2012 at MITRE in Bedford, MA
>
>         Steve....
>
>         ------------------------------------------------------------------------
>
>         *From:*Boczenowski, Steve [[email-masked]
>         <mailto:[email-masked]>]
>         *Sent:* Tuesday, March 20, 2012 16:38
>         *To:* [email-masked]
>         <mailto:[email-masked]>
>         *Subject:* [OVAL-DEVELOPER-LIST] Security Automation Developer
>         Days: Summer 2012 at MITRE in Bedford, MA
>
>         This year’s MITRE-hosted Security Automation Developer Days
>         event will be held during the week of July 9, 2012 at MITRE’s
>         facility in Bedford, MA.
>
>         Details to follow.
>
>         Regards,
>
>         Steve
>
>         /Stephen P. Boczenowski/
>         The MITRECorporation
>         [email-masked] <mailto:[email-masked]>
>
>         To unsubscribe, send an email message to
>         [email-masked] <mailto:[email-masked]> with
>         SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you
>         have difficulties, write to
>         [email-masked]
>         <mailto:[email-masked]>.
>
>         To unsubscribe, send an email message to
>         [email-masked] <mailto:[email-masked]> with
>         SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you
>         have difficulties, write to
>         [email-masked]
>         <mailto:[email-masked]>.
>
>         To unsubscribe, send an email message to
>         [email-masked] <mailto:[email-masked]> with
>         SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you
>         have difficulties, write to
>         [email-masked]
>         <mailto:[email-masked]>.
>
>
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

---

From: Michael Hammer <[email-masked]>
Date: Fri, 11 May 2012 17:07:35 +0000

When you say publish content, is the content still distributed, but index
entries are published somewhere?

You seem to hint at that with the DNS reference, but I'm not sure.

Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Friday, May 11, 2012 12:36 PM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: [sacm] Request for participants - Content Repository Specification
Development

Mike I love it when you tee something up like that.. ;-)  Thank you. ;)

Mike wrote: 

We need to talk more.

Here is how I see the problem.  There is an immediate need for SCAP and
other related content to be served up inside an organization.  Today we have
situation where the standards allow us to provide sites the capability to
have a single SCAP implemented policy they call official for their
environment. Yes this is a rather simplistic since there are things such as
targeting specific platforms, specific operational use needs, but for now
lets agree SCAP is a massive improvement over the proprietary situations of
the past. While we have created this standard content so that sites can
implement their local site security once and then assure they are measuring
all appropriately targeted devices the same way, we have failed to support
the operational needs of the sites.  We have a situation where no two
vendors distribute content the same way.  This causes massive problems for
the administration staff when they need to incorporate a new SCAP enabled
product into their architecture.  They need to discover how the new product
supports distributing SCAP content to it's various components.  If they have
one product then they do this one and they are done.  If they have multiple
products they will have to figure out how to minimize the impact by
incorporating the update process for the new product into the existing SCAP
security content processes. Now when the inevitable happens and the site
staff needs to make a change to their security policy, they have to make the
modifications to the benchmark or checks or both and then distribute those
updates across their network.  For each SCAP enabled product they have in
place, they have doubled, tripled or more the work needed to make those
updates available. 

There is another content repository problem and that is the Federated
Content Distribution.  If you think global DNS you have a general frame of
reference.  The guidance authors need to be able to publish content in an
authoritative manner so their content is updated in a timely fashion.  This
is a much harder problem to solve if there is no local organizational
infrastructure to support it. ;)

So here is what I am thinking.  We should consider addressing these as two
separate but integrated efforts.  I believe the Organizational Content
Repository is the more critical piece that is actually easier to address.
The Federated Content Distribution should be a subsequent effort integrating
/ augmenting the Organizational repository specification. 

Mike, to your point that we need someone to build one first. That has
happened already.  I have one as do other vendors but what we don't have is
the access specification.  Ours are focused on our specific product needs.
Additionally there is a company that has developed a commercial SCAP content
repository that will be announced later this month. I won't steal their
thunder but I was recently given a sneak peek at it and I must admit I was
very impressed.  Again, to your point, it has been done. What is needed to
address the initial operational problem is to develop a specification that
provides a consistent means for all SCAP products to retrieve the
appropriate content as configured and managed but the site.  

TO THAT END..

I am requesting participation from those in the community that see the need
and want to put in the work to make this specification happen.  I have
talked to a couple of you but I do not want to assume your participation.
If you are interested please contact me so we can get this started. 

Thanks!

Kent Landfield

Direct: +1.972.963.7096 
Mobile: +1.817.637.8026

From: <Kinney>, Michael A <[email-masked]>
To: David Waltermire <[email-masked]>, SCAP-DEV
<[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation Developer
Days: Summer 2012 at MITRE in Bedford, MA

Dave,

Thanks for the links.

We need to talk more.

-Mike  

Mike,

Here are the links:

Sincerely,

Dave

Kent,

It's good to read your thoughts, and a realistic actionable approach is
indeed needed.  Since all the activity hasn't been on the lists a brief 1Ž2
hour recap may be in order to bring everyone up to speed since there has
been a lot of activity on CPE/SWID, OCIl, MAEC/CybOX CEE and others.

We could write a content repository specification, but without someone
willing to stand one up it will be as valuable as the CCSS specification is
today.  I've been trying for two years to get my management to get a
coordinated effort together for the DoD to stand up a repository, it is a
tough problem and will require funding with a tail, I'm not sure a
specification will solve that problem.

Remediation is stalled but I'm making every effort to get it kick started

I didn't think that a move to internationalization should impede efforts to

v/r

Mike Kinney

Project Director

 

From:[email-masked] [mailto:[email-masked]] On Behalf Of Waltermire,
David A.

Kent,

objectives, I see no problem with that.  We can also keep a few sessions "on
deck" if all the objectives are reached and we complete all the scheduled
sessions early.

Thoughts?

Sincerely,

David Waltermire

SCAP Architect

(301) 975-3390

From:[email-masked] [mailto:[email-masked]] On Behalf Of

All,

For example:

single local site security policy (XCCDF + OVAL + CPE +.) without the site

I am really disappointed that Remediation is not on the list below.  Yes,

missing pieces..  We need this discussed.

Thanks.

Kent Landfield

Direct: +1.972.963.7096 
Mobile: +1.817.637.8026

Frank;

We hope to have the registration site up next week.  The event will be
during the week of July 9 - starting Monday at 10:00 AM and ending on Friday
at 12:00.

CCE

CPE/SWID

CEE

XCCDF

OVAL

ASR

Enterprise OCIL

CybOX/MAEC

MILE

TAXII

IF-M for SCAP

IF-MAP

SCAP Releases

SCAP and IETF

NETCONF and SCAP

Steve

Steve....

Thanks,
Frank Acker

  _____  

This year's MITRE-hosted Security Automation Developer Days event will be
held during the week of July 9, 2012 at MITRE's facility in Bedford, MA.

Details to follow.

Regards,

    Steve

Stephen P. Boczenowski

      The MITRE Corporation

      Office: (781) 271-7682

      Cell: (978) 302-3849

     [email-masked]

---

From: "Waltermire, David A." <[email-masked]>
Date: Fri, 11 May 2012 13:13:06 -0400

Kent,

I have already started work on a draft specification in this area.  My hope is that this work could be used as an initial draft within SACM at the appropriate time.  Count me in.

I mostly agree with what you are describing below.  The only area I disagree with is in regards to federation.  If we do not implement the specification for an organizational repository in the right way, we may need to make major changes to support federation.  This is not good for anyone.  In my mind these two concepts cannot be decoupled.  We need to insure that any work towards supporting an organizational repository provides a foundation for supporting a federated repository network.  Imagine if DNS was designed with a single organization mindset first without thinking about federation.  Top Level Domains (TLDs) and subdomains would not likely exist as concepts.  An individual DNS server would likely not support caching, time-to-live and delegating capabilities that are necessary for federation to happen.  All of these things would need to be retrofitted.  To prevent this, we need to address the building blocks of federation in the basic design.

Sincerely,
Dave

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, May 11, 2012 12:36 PM
To: [email-masked]; Waltermire, David A.; SCAP-DEV; [email-masked]
Subject: Request for participants - Content Repository Specification Development

Mike I love it when you tee something up like that.... ;-)  Thank you. ;)

Mike wrote:
We need to talk more...

So here is what I am thinking...  We should consider addressing these as two separate but integrated efforts.  I believe the Organizational Content Repository is the more critical piece that is actually easier to address.  The Federated Content Distribution should be a subsequent effort integrating / augmenting the Organizational repository specification.

Mike, to your point that we need someone to build one first... That has happened already.  I have one as do other vendors but what we don't have is the access specification.  Ours are focused on our specific product needs.  Additionally there is a company that has developed a commercial SCAP content repository that will be announced later this month. I won't steal their thunder but I was recently given a sneak peek at it and I must admit I was very impressed.  Again, to your point, it has been done. What is needed to address the initial operational problem is to develop a specification that provides a consistent means for all SCAP products to retrieve the appropriate content as configured and managed but the site.

TO THAT END....

Thanks!

Kent Landfield

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

Dave,

We need to talk more...

-Mike

Mike,

Here are the links:

Sincerely,
Dave

Kent,

It's good to read your thoughts, and a realistic actionable approach is indeed needed.  Since all the activity hasn't been on the lists a brief 1Ž2 hour recap may be in order to bring everyone up to speed since there has been a lot of activity on CPE/SWID, OCIl, MAEC/CybOX CEE and others.

v/r

Mike Kinney
Project Director

Kent,

Thoughts?

Sincerely,

David Waltermire
SCAP Architect

All,

Thanks.

Kent Landfield

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

Frank;

CCE
CPE/SWID
CEE
XCCDF
OVAL
ASR
Enterprise OCIL
CybOX/MAEC

Steve

Steve....

Thanks,
Frank Acker

Details to follow.

Regards,
    Steve

---

From: "Natale, Bob" <[email-masked]>
Date: Fri, 11 May 2012 17:45:19 +0000

With respect specifically to: "I believe the DoD needs to incorporate a metadata repository as part of it" ... have you already (or will you) consider the DoD MetaData Repository (MDR), now best reviewed as part of the overarching Data Services Environment (DSE), https://metadata.ces.mil/dse/homepage.htm.

I am not suggesting that the MDR/DSE provides an appropriate solution for that component or that it does not - just that it's an existing capability that you might want to evaluate as a candidate solution for the metadata repository requirements.

Cheers,
BobN

Dave,

-Mike

---

From: Gunnar Engelbach <[email-masked]>
Date: Fri, 11 May 2012 14:02:53 -0400

It would be great to have as many of these considerations as possible in 
mind from the start as the actual work begins.  As another example, I'd 
like to see active participation from vendors that have commercial 
content repositories so those concerns also don't have to be later 
addressed with major changes.

But we also see a lot of these type of topics come up on the lists, get 
discussed for a bit, then languish.  If reducing the problem set is what 
it takes to spur some action, let's get started.

It kinda sounds like this is headed towards having a dedicated working 
group to take it on, which is what I'd prefer to see, so I'm avoiding 
making specific comments until then.

And my apologies to Dave:  I'd like to see how much you've already 
addressed, but I just haven't had a chance to look through your draft yet.

--gun

ThreatGuard, Inc.

On 5/11/2012 1:13 PM, Waltermire, David A. wrote:
> Kent,
>
> I have already started work on a draft specification in this area.  My
> hope is that this work could be used as an initial draft within SACM at
> the appropriate time.  Count me in.
>
> I mostly agree with what you are describing below.  The only area I
> disagree with is in regards to federation.  If we do not implement the
> specification for an organizational repository in the right way, we may
> need to make major changes to support federation.  This is not good for
> anyone.  In my mind these two concepts cannot be decoupled.  We need to
> insure that any work towards supporting an organizational repository
> provides a foundation for supporting a federated repository network.
> Imagine if DNS was designed with a single organization mindset first
> without thinking about federation.  Top Level Domains (TLDs) and
> subdomains would not likely exist as concepts.  An individual DNS server
> would likely not support caching, time-to-live and delegating
> capabilities that are necessary for federation to happen.  All of these
> things would need to be retrofitted.  To prevent this, we need to
> address the building blocks of federation in the basic design.
>
> Sincerely,
>
> Dave
>
> *From:[email-masked] [mailto:[email-masked]]
> *Sent:* Friday, May 11, 2012 12:36 PM
> *To:* [email-masked]; Waltermire, David A.; SCAP-DEV; [email-masked]
> *Subject:* Request for participants - Content Repository Specification
> Development
>
> *From: *<Kinney>, Michael A <[email-masked]
> <mailto:[email-masked]>>
> *To: *David Waltermire <[email-masked]
> *Subject: *Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation

---

From: "Chandrashekhar B" <[email-masked]>
Date: Sat, 12 May 2012 12:13:29 +0530

Having a standard access interface is really important for content
repository. I had proposed a simple WSDL in a presentation I shared with
Kent, last year's ITSAC. We are looking forward to take active participation
in it.

Thanks,
Chandra.
www.secpod.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Gunnar Engelbach
Sent: Friday, May 11, 2012 11:33 PM
Cc: SCAP-DEV; [email-masked]
Subject: Re: [sacm] Request for participants - Content Repository
Specification Development

It would be great to have as many of these considerations as possible in
mind from the start as the actual work begins.  As another example, I'd like
to see active participation from vendors that have commercial content
repositories so those concerns also don't have to be later addressed with
major changes.

But we also see a lot of these type of topics come up on the lists, get
discussed for a bit, then languish.  If reducing the problem set is what it
takes to spur some action, let's get started.

It kinda sounds like this is headed towards having a dedicated working group
to take it on, which is what I'd prefer to see, so I'm avoiding making
specific comments until then.

--gun

ThreatGuard, Inc.

On 5/11/2012 1:13 PM, Waltermire, David A. wrote:
> So here is what I am thinking. We should consider addressing these as
> happened already. I have one as do other vendors but what we don't have
>     It's good to read your thoughts, and a realistic actionable approach
>     is indeed needed. Since all the activity hasn't been on the lists a
>     specification is today. I've been trying for two years to get my
>     a tail, I'm not sure a specification will solve that problem.
>
>     Remediation is stalled but I'm making every effort to get it kick
>     that I need to wait. I didn't think that a move to
>     sessions "on deck" if all the objectives are reached and we complete
>     share a single local site security policy (XCCDF + OVAL + CPE +.)
>     I am really disappointed that Remediation is not on the list below.
>     as the foundational pieces. But there are missing pieces.. We need
>     this discussed.
>
>         will be during the week of July 9 - starting Monday at 10:00 AM
>         This year's MITRE-hosted Security Automation Developer Days
>         event will be held during the week of July 9, 2012 at MITRE's
>         facility in Bedford, MA.
>
>         Details to follow.
>
>         Regards,
>
>         Steve
>

---

From: "Andrew Bove [SA]" <[email-masked]>
Date: Sat, 12 May 2012 12:27:28 -0400

I would like to participate.

_Andy

Mike wrote: 

We need to talk more.

TO THAT END..

Thanks!

Kent Landfield

Direct: +1.972.963.7096 
Mobile: +1.817.637.8026

Dave,

Thanks for the links.

We need to talk more.

-Mike  

Mike,

Here are the links:

Sincerely,

Dave

Kent,

v/r

Mike Kinney

Project Director

 

Kent,

Thoughts?

Sincerely,

David Waltermire

SCAP Architect

(301) 975-3390

All,

For example:

Thanks.

Kent Landfield

Direct: +1.972.963.7096 
Mobile: +1.817.637.8026

Frank;

CCE

CPE/SWID

CEE

XCCDF

OVAL

ASR

Enterprise OCIL

CybOX/MAEC

MILE

TAXII

IF-M for SCAP

IF-MAP

SCAP Releases

SCAP and IETF

NETCONF and SCAP

Steve

Steve....

Thanks,
Frank Acker

  _____  

Details to follow.

Regards,

    Steve

Stephen P. Boczenowski

      The MITRE Corporation

      Office: (781) 271-7682

      Cell: (978) 302-3849

     [email-masked]

---

From: "Waltermire, David A." <[email-masked]>
Date: Mon, 14 May 2012 15:12:42 -0400

One problem with SOAP web services is that they are often considered very heavy weight.  From what I have seen, the IETF tends to prefer lighter weight protocols (e.g. REST, standardized messages over HTTP, etc).  Anyone else have any insights on this?

Sincerely,
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Chandrashekhar B
Sent: Saturday, May 12, 2012 2:43 AM
To: SCAP-DEV; [email-masked]
Subject: Re: [sacm] Request for participants - Content Repository Specification Development

Having a standard access interface is really important for content repository. I had proposed a simple WSDL in a presentation I shared with Kent, last year's ITSAC. We are looking forward to take active participation in it.

Thanks,
Chandra.
www.secpod.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gunnar Engelbach
Sent: Friday, May 11, 2012 11:33 PM
Cc: SCAP-DEV; [email-masked]
Subject: Re: [sacm] Request for participants - Content Repository Specification Development

It would be great to have as many of these considerations as possible in mind from the start as the actual work begins.  As another example, I'd like to see active participation from vendors that have commercial content repositories so those concerns also don't have to be later addressed with major changes.

But we also see a lot of these type of topics come up on the lists, get discussed for a bit, then languish.  If reducing the problem set is what it takes to spur some action, let's get started.

It kinda sounds like this is headed towards having a dedicated working group to take it on, which is what I'd prefer to see, so I'm avoiding making specific comments until then.

And my apologies to Dave:  I'd like to see how much you've already addressed, but I just haven't had a chance to look through your draft yet.

--gun

ThreatGuard, Inc.

On 5/11/2012 1:13 PM, Waltermire, David A. wrote:
> hope is that this work could be used as an initial draft within SACM
> at the appropriate time.  Count me in.
>
> specification for an organizational repository in the right way, we
> may need to make major changes to support federation.  This is not
> good for anyone.  In my mind these two concepts cannot be decoupled.
> We need to insure that any work towards supporting an organizational
> repository provides a foundation for supporting a federated repository network.
> subdomains would not likely exist as concepts.  An individual DNS
> server would likely not support caching, time-to-live and delegating
> capabilities that are necessary for federation to happen.  All of
> these things would need to be retrofitted.  To prevent this, we need
> to address the building blocks of federation in the basic design.
>
> Sincerely,
>
> Dave
>
> thinking until someone builds one and learns the lessons it will just
> be another whitepaper spec. I believe the DoD needs to incorporate a
> metadata repository as part of it and other customizations that may
> not be useful for everyone.
>
> We need to talk more.
>
> proprietary situations of the past. While we have created this
> standard content so that sites can implement their local site security
> once and then assure they are measuring all appropriately targeted
> devices the same way, we have failed to support the operational needs of the sites.
> way. This causes massive problems for the administration staff when
> they need to incorporate a new SCAP enabled product into their architecture.
> do this one and they are done. If they have multiple products they
> will have to figure out how to minimize the impact by incorporating
> the update process for the new product into the existing SCAP security
> of reference. The guidance authors need to be able to publish content
> in an authoritative manner so their content is updated in a timely fashion.
> Content Repository is the more critical piece that is actually easier
> to address. The Federated Content Distribution should be a subsequent
> happened already. I have one as do other vendors but what we don't
> have is the access specification. Ours are focused on our specific
> product needs. Additionally there is a company that has developed a
> commercial SCAP content repository that will be announced later this
> month. I won't steal their thunder but I was recently given a sneak
> peek at it and I must admit I was very impressed. Again, to your point, it has been done.
> What is needed to address the initial operational problem is to
> develop a specification that provides a consistent means for all SCAP
> products to retrieve the appropriate content as configured and managed
> but the
site.

---

From: <[email-masked]>
Date: Mon, 14 May 2012 14:23:37 -0500

Hi Sean,

Can you help here?  I too have heard that but I want to make sure we are not being confused by hearsay…

Thanks.

Kent Landfield

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

From: <Waltermire>, David Waltermire <[email-masked]<mailto:[email-masked]>>
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, SCAP-DEV <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sacm] Request for participants - Content Repository Specification Development

Sincerely,
Dave

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Chandrashekhar B
Sent: Saturday, May 12, 2012 2:43 AM
To: SCAP-DEV; [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] Request for participants - Content Repository Specification Development

Thanks,
Chandra.
www.secpod.com

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Gunnar Engelbach
Sent: Friday, May 11, 2012 11:33 PM
Cc: SCAP-DEV; [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] Request for participants - Content Repository Specification Development

--gun

ThreatGuard, Inc.

Sincerely,

Dave

*From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
*Sent:* Friday, May 11, 2012 12:36 PM
*To:* [email-masked]<mailto:[email-masked]>; Waltermire, David A.; SCAP-DEV;
[email-masked]<mailto:[email-masked]>
*Subject:* Request for participants - Content Repository Specification
Development

Mike wrote:

We need to talk more.

If you are talking about a holistic, complete federated approach to a
content repository, I some what agree. If you are talking about an
organizational repository, I totally disagree. But you knew I would.
;)

TO THAT END..

Thanks!

*Kent Landfield*

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

*From: *<Kinney>, Michael A <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>>
*To: *David Waltermire <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>>, SCAP-DEV <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>"
<[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>
*Subject: *Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation
Developer Days: Summer 2012 at MITRE in Bedford, MA

     Dave,

     Thanks for the links.

     We need to talk more.

     -Mike

     *To:* Kinney, Michael A; SCAP-DEV; [email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>

     Mike,

     Remediation is a topic near and dear to my heart. I too would like
     to see it move forward.

     Here are the links:

     I am also looking forward to the discussions at the conference. It
     has been too long.

     Sincerely,

     Dave

     Kent,

     v/r

     Mike Kinney

     Project Director

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

     *From:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

     Kent,

     Thoughts?

     Sincerely,

     David Waltermire

     SCAP Architect

     (301) 975-3390

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

     *From:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
     [mailto:[email-masked]] <mailto:[mailto:[email-masked]]> *On
     Behalf Of [email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>
     *Sent:* Monday, May 07, 2012 4:25 PM
     *To:* SCAP-DEV
     *Subject:* Re: [OVAL-DEVELOPER-LIST] Security Automation Developer
     Days: Summer 2012 at MITRE in Bedford, MA

     All,

     I would like to discuss the format for the SCAP Developer Days that
     seems to be listed below.

      1. Presentations are sent out to the attendees and the lists a week
         in advance.

     For example:

     Thanks.

     *Kent Landfield*

     Direct: +1.972.963.7096
     Mobile: +1.817.637.8026

     *From: *<Boczenowski>, Steve <[email-masked]<mailto:[email-masked]>
     <mailto:[email-masked]>>
     *Reply-To: *"OVAL Developer List (Closed Public Discussion)"
     <[email-masked]<mailto:[email-masked]>
     <mailto:[email-masked]>>
     *To: *"[email-masked]<mailto:[email-masked]>
     <mailto:[email-masked]>"
     <[email-masked]<mailto:[email-masked]>
     <mailto:[email-masked]>>
     *Subject: *Re: [OVAL-DEVELOPER-LIST] Security Automation Developer
     Days: Summer 2012 at MITRE in Bedford, MA

         Frank;

         Meanwhile, we are working on the agenda and are currently
         considering this list of topics:

         CCE

         CPE/SWID

         CEE

         XCCDF

         OVAL

         ASR

         Enterprise OCIL

         CybOX/MAEC

         Endpoint Reporting for Continuous Monitoring and Compliance
(ERCC)

         MILE

         TAXII

         IF-M for SCAP

         IF-MAP

         SCAP Releases

         SCAP and IETF

         NETCONF and SCAP

         Steve

         Steve....

         Thanks,
         Frank Acker

         *From:*Boczenowski, Steve [[email-masked]<mailto:[email-masked]>
         <mailto:[email-masked]>]
         *Sent:* Tuesday, March 20, 2012 16:38
         *To:* [email-masked]<mailto:[email-masked]>
         <mailto:[email-masked]>
         *Subject:* [OVAL-DEVELOPER-LIST] Security Automation Developer
         Days: Summer 2012 at MITRE in Bedford, MA

         Details to follow.

         Regards,

         Steve

         /Stephen P. Boczenowski/

         The MITRECorporation

         Office: (781) 271-7682

         Cell: (978) 302-3849

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

         To unsubscribe, send an email message to
         [email-masked]<mailto:[email-masked]> <mailto:[email-masked]> with
         SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you
         have difficulties, write to
         [email-masked]<mailto:[email-masked]>
         <mailto:[email-masked]>.

         To unsubscribe, send an email message to
         [email-masked]<mailto:[email-masked]> <mailto:[email-masked]> with
         SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you
         have difficulties, write to
         [email-masked]<mailto:[email-masked]>
         <mailto:[email-masked]>.

         To unsubscribe, send an email message to
         [email-masked]<mailto:[email-masked]> <mailto:[email-masked]> with
         SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you
         have difficulties, write to
         [email-masked]<mailto:[email-masked]>
         <mailto:[email-masked]>.

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

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

---

From: <[email-masked]>
Date: Mon, 14 May 2012 15:39:35 -0400

Sean - please do chime in.

My .02:   When MILE was INCH, the WG had thought SOAP and BEEP were good solutions to fit the protocol (so the WG can drive what they think is needed).  But the IETF saw that the direction at the time was HTTPS, which would seem to agree with the statement below.  There really were not many BEEP implementations, so it didn't seem practical even if the protocol design was a better fit.  REST wasn't popular then, so we also took the approach to separate out the protocol from the binding to allow for changes later (add new bindings).  With this approach, you can build in the security at the protocol so that you don't rely fully on the binding for authentication and encryption.

Discussions in some WGs have been debating XML or JSON and there are 2 camps here, but the theory of having a data model approach and selecting one for the WG seems to be the go-forward decision.

Best regards,
Kathleen

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, May 14, 2012 3:24 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [sacm] Request for participants - Content Repository Specification Development

Hi Sean,

Can you help here?  I too have heard that but I want to make sure we are not being confused by hearsay...

Thanks.

Kent Landfield

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

Sincerely,
Dave

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Chandrashekhar B
Sent: Saturday, May 12, 2012 2:43 AM
To: SCAP-DEV; [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] Request for participants - Content Repository Specification Development

Thanks,
Chandra.
www.secpod.com

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Gunnar Engelbach
Sent: Friday, May 11, 2012 11:33 PM
Cc: SCAP-DEV; [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] Request for participants - Content Repository Specification Development

--gun

ThreatGuard, Inc.

Sincerely,

Dave

Mike wrote:

We need to talk more.

TO THAT END..

Thanks!

*Kent Landfield*

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

*From: *<Kinney>, Michael A <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]><mailto:[email-masked]%3e>>
*To: *David Waltermire <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]><mailto:[email-masked]%3e>>, SCAP-DEV <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]><mailto:[email-masked]%3e>>, "[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]%3e>"
<[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]%3e>>
*Subject: *Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation
Developer Days: Summer 2012 at MITRE in Bedford, MA

     Dave,

     Thanks for the links.

     We need to talk more.

     -Mike

     Mike,

     Here are the links:

     Sincerely,

     Dave

     Kent,

     v/r

     Mike Kinney

     Project Director

     Kent,

     Thoughts?

     Sincerely,

     David Waltermire

     SCAP Architect

     (301) 975-3390

     All,

     For example:

     Thanks.

     *Kent Landfield*

     Direct: +1.972.963.7096
     Mobile: +1.817.637.8026

     *From: *<Boczenowski>, Steve <[email-masked]<mailto:[email-masked]>
     <mailto:[email-masked]><mailto:[email-masked]%3e>>
     *Reply-To: *"OVAL Developer List (Closed Public Discussion)"
     <[email-masked]<mailto:[email-masked]>
     <mailto:[email-masked]><mailto:[email-masked]%3e>>
     *To: *"[email-masked]<mailto:[email-masked]>
     <mailto:[email-masked]><mailto:[email-masked]%3e>"
     <[email-masked]<mailto:[email-masked]>
     <mailto:[email-masked]><mailto:[email-masked]%3e>>
     *Subject: *Re: [OVAL-DEVELOPER-LIST] Security Automation Developer
     Days: Summer 2012 at MITRE in Bedford, MA

         Frank;

         CCE

         CPE/SWID

         CEE

         XCCDF

         OVAL

         ASR

         Enterprise OCIL

         CybOX/MAEC

         MILE

         TAXII

         IF-M for SCAP

         IF-MAP

         SCAP Releases

         SCAP and IETF

         NETCONF and SCAP

         Steve

         Steve....

         Thanks,
         Frank Acker

         <mailto:[email-masked]><mailto:[email-masked]%3e>]

         Details to follow.

         Regards,

         Steve

         /Stephen P. Boczenowski/

         The MITRECorporation

         Office: (781) 271-7682

         Cell: (978) 302-3849

---

From: Gunnar Engelbach <[email-masked]>
Date: Mon, 14 May 2012 16:13:10 -0400

On the other hand, everything else in the SCAP world is XML-based.  If 
repositories also want to interact with non-SCAP content, a good 
argument could be made for JSON.

It would be good to have the options narrowed down to a most likely set 
so that we've all time to do our research ahead of time.

--gun

On 5/14/2012 3:51 PM, Kurt Seifried wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 05/14/2012 01:28 PM, Waltermire, David A. wrote:
>>
>> One problem with SOAP web services is that they are often
>> considered very heavy weight.  From what I have seen, the IETF
>> tends to prefer lighter weight protocols (e.g. REST, standardized
>> messages over HTTP, etc).  Anyone else have any insights on this?
>>
>> Sincerely, Dave
>
>
> I was watching a presentation on cloud public API's (can't find the
> link) and the current trend is that REST+JSON is winning (like over
> 50%), SOAP/XML are far less popular. I suspect a lot of this is due to
> simplicity/practical/resource issues.
>
>
> - --
> Kurt Seifried Red Hat Security Response Team (SRT)
> PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQIcBAEBAgAGBQJPsV7YAAoJEBYNRVNeJnmT4dYP/1e1FOuKHyFpn3G8mvPZwfSu
> z2C2dx32MGQU0ZsOW+9dVuZbvCMQKct2QSTEFCJc31Vrt8cv3w2C4tMXUfuEeDn+
> wbzEa4M3Pu0HHxx+XboaNHCSFKDdXACKcAvSjC1bG+SGcQLpr542BpH+08p987o3
> DgOZAOoA65cUJXep7O+OcvrYwVL/BY/m4aY9ClvwFogKhbn2c7K1nDnMudaPxohS
> 7M9WR7sWwMYMVtjfQVGmqDkf+eq8h3aVN+cxjdDGkZVhffBslP3x5LUAtakmGDOw
> X34WJYGkKSERVL6PxCAUZUvtLqDN6Zq1AU62RP9RIztKjbPSFckrBXVPXPGyVOLQ
> RTFh9YF+zQgX/3C9yhXF7uUMN0SdsN3NVETHwww3CqiwD0Qg4QKFmGritiMU5VVJ
> uqX6WXROhqzAgr3nPJe/WbC//ckGKsVO4JOctbQmFzdxK8+HgMqrRUc6KdGJkyWo
> JJBdW3D828MgOA0G4emvbWHh1bYlGuacO0I4/t27xQFEZ/UdJMRsEh+7hTAZd16j
> OYfMunX9PlpvZFsHmvcMTybIOz3PApz0ob8fzF/vOD7r4VrNHGEqPZF6GyllvLw3
> qxYDGfzeDtaoT5p6V0bptUzAcR3y0DRHQBJTl/Ai2ejTN8K1pYDUBONTGhnkLp10
> jvOC5WFffjgysH0hKE5g
> =YuOG
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------
>
> To unsubscribe from this mailing list, please send an e-mail to
> [email-masked] with the words "unsubscribe scap-dev" in the body. You
> will need to send this from the email account that you used to initially
> subscribe to scap-dev.
>

---

From: "Waltermire, David A." <[email-masked]>
Date: Mon, 14 May 2012 16:36:57 -0400

Something like this technique could be used to support JSON in XML.

http://jsontoxml.utilities-online.info/

Both are hierarchical in nature.  Information can be easily marshaled either way.

Sincerely,
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gunnar Engelbach
Sent: Monday, May 14, 2012 4:27 PM
To: SCAP-DEV
Subject: Re: [sacm] Request for participants - Content Repository Specification Development

On the other hand, everything else in the SCAP world is XML-based.  If repositories also want to interact with non-SCAP content, a good argument could be made for JSON.

It would be good to have the options narrowed down to a most likely set so that we've all time to do our research ahead of time.

--gun

---

From: "Waltermire, David A." <[email-masked]>
Date: Wed, 16 May 2012 15:38:55 -0400

I just posted a skeleton I/D on this topic.  I have included an initial section that focuses on identifying the overall problem space relating to content repositories.  I'd appreciate any comments.

Here is the draft:
http://www.ietf.org/id/draft-waltermire-content-repository-00.txt

Sincerely,
Dave

From: Waltermire, David A.
Sent: Friday, May 11, 2012 1:13 PM
To: [email-masked]'; [email-masked]; SCAP-DEV; [email-masked]
Subject: RE: Request for participants - Content Repository Specification Development

Kent,

Sincerely,
Dave

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Friday, May 11, 2012 12:36 PM
To: [email-masked]<mailto:[email-masked]>; Waltermire, David A.; SCAP-DEV; [email-masked]<mailto:[email-masked]>
Subject: Request for participants - Content Repository Specification Development

Mike wrote:

TO THAT END....

Thanks!

Kent Landfield

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

Dave,

-Mike

Mike,

Here are the links:

Sincerely,
Dave

Kent,

v/r

Mike Kinney
Project Director

Kent,

Thoughts?

Sincerely,

David Waltermire
SCAP Architect

All,

Thanks.

Kent Landfield

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

Frank;

CCE
CPE/SWID
CEE
XCCDF
OVAL
ASR
Enterprise OCIL
CybOX/MAEC

Steve

Steve....

Thanks,
Frank Acker

Details to follow.

Regards,
    Steve

---

From: "Panos Kampanakis" <[email-masked]>
Date: Thu, 17 May 2012 18:29:48 -0400

Good starting point Dave.

2 thoughts: 

- Integrity and Confidentiality can certainly be addressed in this spec. But
XML has its own mechanisms to provide them. Thus the content itself can
provide Integrity and Confidentiality. I am not sure if the spec should have
Integrity and Confidentiality as required features.

- Also, should the data Exchange mechanism be part of this draft? For
example HTTP/TLS messages etc (as in MILE's rfc6546) or JSON, SOAP, REST as
were suggested in SACM's alias before?

Rgs,

Panos

Waltermire, David A.
Sent: Wednesday, May 16, 2012 3:39 PM

I just posted a skeleton I/D on this topic.  I have included an initial
section that focuses on identifying the overall problem space relating to
content repositories.  I'd appreciate any comments.

Here is the draft:

Sincerely,

Dave

From: Waltermire, David A. 
Sent: Friday, May 11, 2012 1:13 PM
To: [email-masked]'; [email-masked]; SCAP-DEV;
[email-masked]
Subject: RE: Request for participants - Content Repository Specification
Development

Kent,

I have already started work on a draft specification in this area.  My hope
is that this work could be used as an initial draft within SACM at the
appropriate time.  Count me in.

I mostly agree with what you are describing below.  The only area I disagree
with is in regards to federation.  If we do not implement the specification
for an organizational repository in the right way, we may need to make major
changes to support federation.  This is not good for anyone.  In my mind
these two concepts cannot be decoupled.  We need to insure that any work
towards supporting an organizational repository provides a foundation for
supporting a federated repository network.  Imagine if DNS was designed with
a single organization mindset first without thinking about federation.  Top
Level Domains (TLDs) and subdomains would not likely exist as concepts.  An
individual DNS server would likely not support caching, time-to-live and
delegating capabilities that are necessary for federation to happen.  All of
these things would need to be retrofitted.  To prevent this, we need to
address the building blocks of federation in the basic design.

Sincerely,

Dave

From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, May 11, 2012 12:36 PM
To: [email-masked]; Waltermire, David A.; SCAP-DEV; [email-masked]
Subject: Request for participants - Content Repository Specification
Development

Mike wrote: 

We need to talk more.

TO THAT END..

Thanks!

Kent Landfield

Direct: +1.972.963.7096 
Mobile: +1.817.637.8026

Dave,

Thanks for the links.

We need to talk more.

-Mike  

Mike,

Here are the links:

Sincerely,

Dave

Kent,

v/r

Mike Kinney

Project Director

 

Kent,

Thoughts?

Sincerely,

David Waltermire

SCAP Architect

(301) 975-3390

All,

For example:

Thanks.

Kent Landfield

Direct: +1.972.963.7096 
Mobile: +1.817.637.8026

Frank;

CCE

CPE/SWID

CEE

XCCDF

OVAL

ASR

Enterprise OCIL

CybOX/MAEC

MILE

TAXII

IF-M for SCAP

IF-MAP

SCAP Releases

SCAP and IETF

NETCONF and SCAP

Steve

Steve....

Thanks,
Frank Acker

  _____  

Details to follow.

Regards,

    Steve

Stephen P. Boczenowski

      The MITRE Corporation

      Office: (781) 271-7682

      Cell: (978) 302-3849

     [email-masked]

---

From: "Waltermire, David A." <[email-masked]>
Date: Thu, 17 May 2012 18:44:56 -0400

Good points.  It makes sense to use the mechanisms provided by XML (e.g. XMLDsig, XML Encryption) and capabilities provided by the underlying transport (e.g. TLS) to address as much of this as possible.  It may be desirable to provide mechanisms for authentication to restrict access to content.  This may also need to be integrated into the underlying transport.

I have been on the fence about having a single mandatory-to-implement communications protocol that is part of the draft or to define a second draft that will address one possible transport approach (e.g. RFC6546). This question doesn't need to get answered right away, but the answer will have impact on how much interoperability is possible. I'm not sure what the right answer is or if there is one right now.

For our content repository prototyping efforts, we are developing REST interfaces with use of JSON to express query parameters. I'd be glad to share our implementation and lessons learned on this when we get to a suitable point.  My hope is that our work will help inform some of the discussion around transport or at least provide a few data points.

Sincerely,
Dave

From: Panos Kampanakis [mailto:[email-masked]]
Sent: Thursday, May 17, 2012 6:30 PM
To: Waltermire, David A.; SCAP-DEV; [email-masked]
Subject: RE: [sacm] Request for participants - Content Repository Specification Development

2 thoughts:

- Integrity and Confidentiality can certainly be addressed in this spec. But XML has its own mechanisms to provide them. Thus the content itself can provide Integrity and Confidentiality. I am not sure if the spec should have Integrity and Confidentiality as required features.

- Also, should the data Exchange mechanism be part of this draft? For example HTTP/TLS messages etc (as in MILE's rfc6546) or JSON, SOAP, REST as were suggested in SACM's alias before?

Rgs,
Panos

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Waltermire, David A.
Sent: Wednesday, May 16, 2012 3:39 PM
To: SCAP-DEV; [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] Request for participants - Content Repository Specification Development

Here is the draft:

Sincerely,
Dave

From: Waltermire, David A.
Sent: Friday, May 11, 2012 1:13 PM
To: [email-masked]'; [email-masked]<mailto:[email-masked]>; SCAP-DEV; [email-masked]<mailto:[email-masked]>
Subject: RE: Request for participants - Content Repository Specification Development

Kent,

Sincerely,
Dave

Mike wrote:

TO THAT END....

Thanks!

Kent Landfield

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

Dave,

-Mike

Mike,

Here are the links:

Sincerely,
Dave

Kent,

v/r

Mike Kinney
Project Director

Kent,

Thoughts?

Sincerely,

David Waltermire
SCAP Architect

All,

Thanks.

Kent Landfield

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

Frank;

CCE
CPE/SWID
CEE
XCCDF
OVAL
ASR
Enterprise OCIL
CybOX/MAEC

Steve

Steve....

Thanks,
Frank Acker

Details to follow.

Regards,
    Steve

---

From: "Waltermire, David A." <[email-masked]>
Date: Thu, 17 May 2012 21:57:14 -0400

Kurt,

My assumption is that each organization would stand up a content repository based on this specification for their own authoritative content, content they produce.  They would sign the content using their own private key or cert. I haven't worked out an approach for public key distribution yet.  It would be nice if we could use DNS or some other standardized key distribution mechanism.  I am looking for ideas.

It may also make sense to allow for counter signing of content to allow 3rd parties to sign content.  Again, I have not worked out how best to do this.  Any ideas?

Related to restricting access to content, it is my hope that the bulk of content in the security automation community is made freely available.  Regardless, it probably makes sense to support some kind of access control.  This could be driven by commercialization of content or to restrict access to some content to authorized users within an organization.  Client/Server certificates might be a mechanism to support this, but we may need to look at other options as well.

I hope this answers your questions.

Sincerely,
Dave

-----Original Message-----
From: Kurt Seifried [mailto:[email-masked]] 
Sent: Thursday, May 17, 2012 9:11 PM
To: Waltermire, David A.
Subject: Re: [scap-dev] [sacm] Request for participants - Content Repository Specification Development

On 05/17/2012 04:44 PM, Waltermire, David A. wrote:
> Good points.  It makes sense to use the mechanisms provided by XML 
> (e.g. XMLDsig, XML Encryption) and capabilities provided by the 
> underlying transport (e.g. TLS) to address as much of this as 
> possible.  It may be desirable to provide mechanisms for 
> authentication to restrict access to content.  This may also need to 
> be integrated into the underlying transport.

I have some questions:

1) if using XMLDsig who would be the signing authority? How secure would signing be (e.g. using a hardware card/appliance/etc?). Where would the key be published/would it be signed/etc?
2) You mention restricting access to content, why would the content need to be restricted? Are there IP issues I am unaware of?

Thanks

- --

---

From: "Waltermire, David A." <[email-masked]>
Date: Thu, 17 May 2012 22:31:34 -0400

Comments inline marked [DAW].

Sincerely,
Dave

-----Original Message-----
From: Kurt Seifried [mailto:[email-masked]] 
Sent: Thursday, May 17, 2012 10:18 PM
To: Waltermire, David A.
Cc: [email-masked]
Subject: Re: [scap-dev] [sacm] Request for participants - Content Repository Specification Development

Note: all opinions/comments are my own, not official Red Hat policy and so on.

On 05/17/2012 07:19 PM, Waltermire, David A. wrote:
> Kurt,
> 
> My assumption is that each organization would stand up a content 
> repository based on this specification for their own authoritative 
> content, content they produce.  They would sign the content using 
> their own private key. I haven't worked out an approach for public key 
> distribution yet.  It would be if we could use DNS or some other 
> standardized key distribution mechanism.  I am open to ideas.

Ah my bad I assumed you guys were talking about the central repo (although at some point there has to be a head repo, right?). As far as keys go why recreate the wheel? Use X.509 and sign stuff, then key distribution is trivial (use the system keys, allow import of a custom key, etc.). Plus this way you're using well tested system libraries/etc. which are available by default (well on any sane OS).

[DAW: I am assuming that there will be no central repo. From talking with content publishers, there are IP rights and other issues with this type of approach.  I think the better solution is to support a distributed network of repositories.  Some organizations and consortiums may decide to stand up centralized repos for their own purposes.  This should be allowed, but not required.

As far as supporting repo resolution, I am recommending a namespaced content identifier approach based on DNS names.  Many of the security automation identifiers have reverse DNS names incorporated into them.  For those that done, simple DNS namespace qualification would provide the same effect.  In either case, this info can be used to lookup the content repository that is authoritative for the content referenced by the ID.  This can be handled using a DNS SRV record (RFC2783).  We would need to get an IANA allocation for this (RFC6335).  This approach avoids having to create a root server infrastructure for content repositories.

I'd like to hear other thoughts related to X.509.]

> It may also make sense to allow for counter signing of content to 
> allow 3rd parties to sign content.  Again, I have not worked out how 
> best to do this.  Any ideas?

Chained signatures would be really nice, e.g. Linux vendor releases an RPM with signed files, customer can then certify them and sign them, so if you allowed people to simply sign data (so "sign1(data)") and in turn that to be signed (e.g. "sign2(sign1(data))") you could support any reasonably sane use case (e.g. we require the sysadmin to use a departmentally signed thing which in turn requires an org cert which requires a gov cert which requires to vendor signature, etc.). I don't think the case of having multiple signatures "At the same level" is significant, and can be fudged using signature chains.

[DAW: agreed.]

> Related to restricting access to content, it is my hope that content 
> is made freely available.  For some kinds of content, it probably 
> makes sense to support some kind of access control.  This could be 
> driven by commercialization of content or to restrict access to some 
> content to authorized users within an organization.
> Client/Server certificates might be a mechanism to support this.

I would classify content rights management as well beyond the scope of this project (you know have to basically build a CA type entity, handle cert revocation for expired clients, etc, etc, etc.) and something to be left up to the end vendor/customer that actually wants this. Building in DRM is a huge amount of effort and I suspect it would mostly be wasted. Any content management you build in will:

1) be incompatible (and thus either removed, or an active problem) for many vendors/customers (I doubt any existing system for selling content will end up being super compatible with what you guys build)
2) be unnecessary in most (if not almost all) cases
3) add significantly to the overhead of building this and not add any real value to the actual problem space of securing machines

For some idea of the scope of this type of problem check out
http://www.candlepinproject.org/   which provides subscription and
entitlement management. Even without reinventing the wheel, but just integrating with something like candlepin would be a huge effort. I would say this problem is left to any vendors that want to put DRM on the content/etc.

TLDR: Please, please don't do this, it'll be a huge time/effort sink and not worth it. Anyone that wants to sell this kind of thing already has systems capable of delivering files and managing access/rights to them.

[DAW: Points well taken.  I am interested in other thoughts on how best to address this.  What I was recommending was looking more towards service authentication and less towards DRM. Maybe we don't address this in the first pass.  Thoughts?]

> -----Original Message----- From: Kurt Seifried 
> [mailto:[email-masked]] Sent: Thursday, May 17, 2012 9:11 PM
> To: Waltermire, David A. Subject: Re: [scap-dev] [sacm] Request for 
> participants - Content Repository Specification Development
> 
> I have some questions, asking off list, not sure if they are 
> appropriate, if they are feel free to reply on the list.
> 
> 1) if using XMLDsig who would be the signing authority? How secure 
> would signing be (e.g. using a hardware card/appliance/etc?).
> Where would the key be published/would it be signed/etc? 2) You 
> mention restricting access to content, why would the content need to 
> be restricted? Are there IP issues I am unaware of?
> 
> Thanks
> 
>> Sincerely, Dave
> 
- - --
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

=QJsL
-----END PGP SIGNATURE-----

---

From: Kurt Seifried <[email-masked]>
Date: Thu, 17 May 2012 20:17:44 -0600

Note: all opinions/comments are my own, not official Red Hat policy
and so on.

On 05/17/2012 07:19 PM, Waltermire, David A. wrote:
> their own private key. I haven't worked out an approach for public
> key distribution yet.  It would be if we could use DNS or some
> other standardized key distribution mechanism.  I am open to
> ideas.

Ah my bad I assumed you guys were talking about the central repo
(although at some point there has to be a head repo, right?). As far
as keys go why recreate the wheel? Use X.509 and sign stuff, then key
distribution is trivial (use the system keys, allow import of a custom
key, etc.). Plus this way you're using well tested system
libraries/etc. which are available by default (well on any sane OS).

> allow 3rd parties to sign content.  Again, I have not worked out
> how best to do this.  Any ideas?

Chained signatures would be really nice, e.g. Linux vendor releases an
RPM with signed files, customer can then certify them and sign them,
so if you allowed people to simply sign data (so "sign1(data)") and in
turn that to be signed (e.g. "sign2(sign1(data))") you could support
any reasonably sane use case (e.g. we require the sysadmin to use a
departmentally signed thing which in turn requires an org cert which
requires a gov cert which requires to vendor signature, etc.). I don't
think the case of having multiple signatures "At the same level" is
significant, and can be fudged using signature chains.

> Related to restricting access to content, it is my hope that
> content is made freely available.  For some kinds of content, it
> probably makes sense to support some kind of access control.  This
> could be driven by commercialization of content or to restrict
> access to some content to authorized users within an organization. 

I would classify content rights management as well beyond the scope of
this project (you know have to basically build a CA type entity,
handle cert revocation for expired clients, etc, etc, etc.) and
something to be left up to the end vendor/customer that actually wants
this. Building in DRM is a huge amount of effort and I suspect it
would mostly be wasted. Any content management you build in will:

1) be incompatible (and thus either removed, or an active problem) for
many vendors/customers (I doubt any existing system for selling
content will end up being super compatible with what you guys build)
2) be unnecessary in most (if not almost all) cases
3) add significantly to the overhead of building this and not add any
real value to the actual problem space of securing machines

For some idea of the scope of this type of problem check out
http://www.candlepinproject.org/   which provides subscription and
entitlement management. Even without reinventing the wheel, but just
integrating with something like candlepin would be a huge effort. I
would say this problem is left to any vendors that want to put DRM on
the content/etc.

TLDR: Please, please don't do this, it'll be a huge time/effort sink
and not worth it. Anyone that wants to sell this kind of thing already
has systems capable of delivering files and managing access/rights to
them.

> To: Waltermire, David A. Subject: Re: [scap-dev] [sacm] Request
> for participants - Content Repository Specification Development
> 
>> Good points.  It makes sense to use the mechanisms provided by
>> XML (e.g. XMLDsig, XML Encryption) and capabilities provided by
>> the underlying transport (e.g. TLS) to address as much of this
>> as possible.  It may be desirable to provide mechanisms for 
>> authentication to restrict access to content.  This may also need
>> to be integrated into the underlying transport.
> mention restricting access to content, why would the content need
> to be restricted? Are there IP issues I am unaware of?
> 
> Thanks
> 
>> Sincerely, Dave
> 
- - --

---

From: "Chandrashekhar B" <[email-masked]>
Date: Fri, 18 May 2012 11:19:54 +0530

My comments marked [CHA]

Chandra.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Waltermire, David A.
Sent: Friday, May 18, 2012 8:02 AM
To: Kurt Seifried
Cc: [email-masked]
Subject: Re: [sacm] [scap-dev] Request for participants - Content Repository
Specification Development

Sincerely,
Dave

-----Original Message-----
From: Kurt Seifried [mailto:[email-masked]]
Sent: Thursday, May 17, 2012 10:18 PM
To: Waltermire, David A.
Cc: [email-masked]
Subject: Re: [scap-dev] [sacm] Request for participants - Content Repository

Note: all opinions/comments are my own, not official Red Hat policy and so
on.

> standardized key distribution mechanism.  I am open to ideas.

Ah my bad I assumed you guys were talking about the central repo (although
at some point there has to be a head repo, right?). As far as keys go why
recreate the wheel? Use X.509 and sign stuff, then key distribution is
trivial (use the system keys, allow import of a custom key, etc.). Plus this
way you're using well tested system libraries/etc. which are available by
default (well on any sane OS).

[DAW: I am assuming that there will be no central repo. From talking with
content publishers, there are IP rights and other issues with this type of
approach.  I think the better solution is to support a distributed network
of repositories.  Some organizations and consortiums may decide to stand up
centralized repos for their own purposes.  This should be allowed, but not
required.

[CHA: Yes, distributed network of repository, with may be a central
registry. Even for a central registry, I feel we aren't there yet. Central
repository or a registry would mean getting into operational aspects, who'll
own, manage, control etc., So, limiting it to organizational repositories
and content providers repository is good in my view.]

As far as supporting repo resolution, I am recommending a namespaced content
identifier approach based on DNS names.  Many of the security automation
identifiers have reverse DNS names incorporated into them.  For those that
done, simple DNS namespace qualification would provide the same effect.  In
either case, this info can be used to lookup the content repository that is
authoritative for the content referenced by the ID.  This can be handled
using a DNS SRV record (RFC2783).  We would need to get an IANA allocation
for this (RFC6335).  This approach avoids having to create a root server
infrastructure for content repositories.

[CHA: I am not sure if I understand the DNS resolution approach here
completely, will anyway pose a question. If one content repository were to
host a content authored by someone else and the namespace wasn't modified,
may be for IP reasons. DNS namespace qualification would not work if I want
to pick the content from this repository instead of the original author. Not
sure if I am making sense :) ]

> best to do this.  Any ideas?

Chained signatures would be really nice, e.g. Linux vendor releases an RPM
with signed files, customer can then certify them and sign them, so if you
allowed people to simply sign data (so "sign1(data)") and in turn that to be
signed (e.g. "sign2(sign1(data))") you could support any reasonably sane use
case (e.g. we require the sysadmin to use a departmentally signed thing
which in turn requires an org cert which requires a gov cert which requires
to vendor signature, etc.). I don't think the case of having multiple
signatures "At the same level" is significant, and can be fudged using
signature chains.

[DAW: agreed.]

> Client/Server certificates might be a mechanism to support this.

I would classify content rights management as well beyond the scope of this
project (you know have to basically build a CA type entity, handle cert
revocation for expired clients, etc, etc, etc.) and something to be left up
to the end vendor/customer that actually wants this. Building in DRM is a
huge amount of effort and I suspect it would mostly be wasted. Any content
management you build in will:

1) be incompatible (and thus either removed, or an active problem) for many
vendors/customers (I doubt any existing system for selling content will end
up being super compatible with what you guys build)
2) be unnecessary in most (if not almost all) cases
3) add significantly to the overhead of building this and not add any real
value to the actual problem space of securing machines

For some idea of the scope of this type of problem check out
http://www.candlepinproject.org/   which provides subscription and
entitlement management. Even without reinventing the wheel, but just
integrating with something like candlepin would be a huge effort. I would
say this problem is left to any vendors that want to put DRM on the
content/etc.

TLDR: Please, please don't do this, it'll be a huge time/effort sink and not
worth it. Anyone that wants to sell this kind of thing already has systems
capable of delivering files and managing access/rights to them.

[DAW: Points well taken.  I am interested in other thoughts on how best to
address this.  What I was recommending was looking more towards service
authentication and less towards DRM. Maybe we don't address this in the
first pass.  Thoughts?]

[CHA: Access control is definitely a requirement for organizational content
server as well as content providers repository. Once the service is
authenticated, it should be left to the implementers to define/implement
their own access rights. Because, an entity communicating with the
repository will not see any difference in the behavior. 

In our repository, we have implemented a policy driven access control and
the policy parameters are the attributes of SCAP metadata. But, someone else
might choose an hierarchical database and define container level access
control. 

So, service authentication is required to be standardized. For access
control, may be an error condition if one is not allowed to fetch the
content?]

- - --
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 -----BEGIN
PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

=QJsL

---

From: "Waltermire, David A." <[email-masked]>
Date: Fri, 18 May 2012 08:42:09 -0400

My comments marked with [DAW2].

Sincerely,
Dave

-----Original Message-----
From: Chandrashekhar B [mailto:[email-masked]] 
Sent: Friday, May 18, 2012 1:50 AM
To: Waltermire, David A.; 'Kurt Seifried'
Cc: [email-masked]; SCAP-DEV
Subject: RE: [sacm] [scap-dev] Request for participants - Content Repository Specification Development

My comments marked [CHA]

Chandra.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Waltermire, David A.
Sent: Friday, May 18, 2012 8:02 AM
To: Kurt Seifried
Cc: [email-masked]
Subject: Re: [sacm] [scap-dev] Request for participants - Content Repository Specification Development

Sincerely,
Dave

-----Original Message-----
From: Kurt Seifried [mailto:[email-masked]]
Sent: Thursday, May 17, 2012 10:18 PM
To: Waltermire, David A.
Cc: [email-masked]
Subject: Re: [scap-dev] [sacm] Request for participants - Content Repository Specification Development

[CHA: Yes, distributed network of repository, with may be a central registry. Even for a central registry, I feel we aren't there yet. Central repository or a registry would mean getting into operational aspects, who'll own, manage, control etc., So, limiting it to organizational repositories and content providers repository is good in my view.]

[DAW2: This is why I am advocating for a federated system.  With the right approach, we can avoid having to stand up a single central registry and all the operational and logistical aspects involved. Using the DNS SRV approach below, DNS essentially becomes the registry.  Using DNS, every organization that produces content is able to point to the authoritative content repositories that they use to host their content. They can create as many namespaces as needed, by using sub-domains within their own domain(s). A SRV record would be associated with each sub-domain in this case.]

[CHA: I am not sure if I understand the DNS resolution approach here completely, will anyway pose a question. If one content repository were to host a content authored by someone else and the namespace wasn't modified, may be for IP reasons. DNS namespace qualification would not work if I want to pick the content from this repository instead of the original author. Not sure if I am making sense :) ]

[DAW2: I am modeling this approach after DNS.  There are authoritative content servers that originate content.  The DNS SRV records would be mapped to the DNS namespaces hosted by a given authoritative content server.  This is an analog to domains hosted by an authoritative DNS server.  Here is a basic communication flow:

1) Client: sends request for content by ID to local, organizational content repository.
2) Organizational repository: retrieve the requested content
  a) If the namespace is a local namespace, return the content.
  b) If the namespace is a foreign namespace, check if the content is in the local cache.
  c) Lookup the DNS SRV record associated with the ID's namespace.
  d) Dispatch a request to the foreign authoritative content repository based on the SRV record to retrieve the content
  e) Cache the retrieved content using the time-to-live (TTL) value provided by the remote server.
3) Organizational repository: respond to the client with the content

This approach allows content for a given namespace to be managed by a single authoritative content repository.  If a third party is hosting content for another (e.g. repository-as-a-service), then the DNS SRV record for the content's ID namespace would point to the 3rd party hosted repository.

Access to local cache can (and probably should) be limited to IPs within an organization or thru the use of access controls to prevent leakage of cached content.]

[DAW: agreed.]

[CHA: Access control is definitely a requirement for organizational content server as well as content providers repository. Once the service is authenticated, it should be left to the implementers to define/implement their own access rights. Because, an entity communicating with the repository will not see any difference in the behavior. 

In our repository, we have implemented a policy driven access control and the policy parameters are the attributes of SCAP metadata. But, someone else might choose an hierarchical database and define container level access control. 

So, service authentication is required to be standardized. For access control, may be an error condition if one is not allowed to fetch the content?]

[DAW2: agreed.  I see this as a minimal standardization approach.]

- - --

=QJsL

---

From: "Waltermire, David A." <[email-masked]>
Date: Fri, 18 May 2012 10:24:46 -0400

In a REST scenerio, a HTTP GET request would be used for querying.  The problem is, and correct me if I am wrong, that HTTP GET semantics require that a resource be retrieved based on the request URI.  This works for simple id lookups, but does not work well if you want to form a query around complex boolean criteria where grouping is needed.  For this we may need to use JSON to encode the query parameters as a request parameter.

I would expect the response to be XML.

Sincerely,

David Waltermire
SCAP Architect

> From: WOLFKIEL, JOSEPH L CIV DISA PEO-MA
> [mailto:[email-masked]]
> Sent: Friday, May 18, 2012 9:42 AM
> To: Panos Kampanakis; Waltermire, David A.; SCAP-DEV; [email-masked]
> Subject: RE: [scap-dev] [sacm] Request for participants - Content
> RepositorySpecification Development
>
> If we're trying for interoperability, it seems like we'll need to
> specify the transport and security.  I'd hate to end up with something
> where every consumer must be able to consume any combination of JSON,
> XML, CSV over REST or SOAP because we didn't pick a standard
> configuration.
>
> I like using REST if possible because the DoD in the Web Services STIG
> has made SOAP-based web services difficult and expensive.  I like XML
> because we already have to do XML parsing for OVAL and XCCDF, so I
> don't really see the allure of having to parse JSON for the service
> then having to parse XML for the content.
>
> Joseph L. Wolfkiel
> Engineering Group Lead
> DISA PEO MA/IA52
> (301) 225-8820
> [email-masked]
>
>
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Panos Kampanakis
> To: 'Waltermire, David A.'; SCAP-DEV; [email-masked]
> Subject: Re: [scap-dev] [sacm] Request for participants - Content
> RepositorySpecification Development
>
> - Integrity and Confidentiality can certainly be addressed in this
> spec. But XML has its own mechanisms to provide them. Thus the content
> itself can provide Integrity and Confidentiality. I am not sure if the
> spec should have Integrity and Confidentiality as required features.
>
>
>
> example HTTP/TLS messages etc (as in MILE's rfc6546) or JSON, SOAP,
> REST as were suggested in SACM's alias before?
>
>
>
> Rgs,
>
> Panos
>
>
>
>
>
>
>
> section that focuses on identifying the overall problem space relating
> to content repositories.  I'd appreciate any comments.
>
>
>
> Here is the draft:
>
> they need to incorporate a new SCAP enabled product into their
> architecture.  They need to discover how the new product supports
> distributing SCAP content to it's various components.  If they have one
> product then they do this one and they are done.  If they have multiple
> incorporating the update process for the new product into the existing
> SCAP security content processes. Now when the inevitable happens and
> the site staff needs to make a change to their security policy, they
> have to make the modifications to the benchmark or checks or both and
> then distribute those updates across their network.  For each SCAP
> enabled product they have in place, they have doubled, tripled or more
> the work needed to make those updates available.
>
>
>
> in an authoritative manner so their content is updated in a timely
> fashion.  This is a much harder problem to solve if there is no local
> peek at it and I must admit I was very impressed.  Again, to your
> point, it has been done. What is needed to address the initial
> operational problem is to develop a specification that provides a
> consistent means for all SCAP products to retrieve the appropriate
> content as configured and managed but the site.
>
>
>
> TO THAT END..
>
>
>
> To: David Waltermire <[email-masked]>, SCAP-DEV <SCAP-
> [email-masked]>, "[email-masked]" <[email-masked]>
> actionable and use it to make decisions, and vote and accomplish things
> good or bad.  I do not want this to be an informational briefing
> conference.
>
>       Thanks for the links.
>
>
>
>       Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer
>       Regarding content management, we are building the prototype
> content repository for use in a production environment.  As an open
> source project, it will be free for use by anyone interested.  My
> thinking is that this project can bridge the gap until commercial
> solutions are available to augment it.  This is a similar path that was
> followed with DNS (bind) and HTTP (apache).  When it is ready for use,
> I am hoping to use it to host USGCB content.  You would be welcome to
> use it for your needs.
>
>
>
>       It is good that OCIL is moving forward.  This is an important
> piece of supporting risk management and aspects of continuous
> monitoring.  I would also like to see some discussion on OCIL at
> Developer Days.  With the proposals we will likely have a sense of what
> needs to be discussed and what we can achieve consensus on outside the
> meeting.
>
>
>
> internationalization issue. Many vendors have commented that they are
> still working on implementing the XCCDF 1.2.1 specification. We will be
> in a better place in a few months once more development around XCCDF
> has occurred.  As we consider changes to the SCAP stack to address OCIL
> and other issues, we will identify areas that need improvement in
> XCCDF.  These are good and necessary discussions to have now, but we
> have a good deal of work to do before we are ready to open up XCCDF.
> My suggestion is to work on these related areas and then work up change
> proposals for XCCDF as needed.  By that time we should be ready to work
> on a new revision of XCCDF.
>
>
>
>       Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer
>       It's good to read your thoughts, and a realistic actionable
> approach is indeed needed.  Since all the activity hasn't been on the
> lists a brief 1Ž2 hour recap may be in order to bring everyone up to
> speed since there has been a lot of activity on CPE/SWID, OCIl,
> MAEC/CybOX CEE and others.
>
>
>
> management to get a coordinated effort together for the DoD to stand up
> a repository, it is a tough problem and will require funding with a
> tail, I'm not sure a specification will solve that problem.
>
>
>
>       We (DoD) have been putting a lot of effort into OCIL over the
> last year trying to make it useful in an enterprise environment and
> will be posting our ideas to the list before developer days it should
> started from our perspective. I hope to assist in getting the draft ERI
> finished this year.  We are writing some new STIG content and intend to
> used the draft CRE specification to insert CRE into the content so we
> (DoD) can do some automatic configuration fixes, part of a self healing
> network concept. It is just a start but the best we can do at this
> point.
>
>
>
>       Enterprise reporting is an interesting subject, since XML adds
> size to and content to roll up reporting, in any enterprise of size the
>       I am concerned that the internationalization efforts are
> detracting from efforts to meet use cases, we have some things we would
> like changed in XCCDF to support our OCIl use case and I have been told
> that I need to wait. I didn't think that a move to internationalization
> should impede efforts to move forward with use cases.
>
>
>
>       Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer
>       I like what you are saying here.  We are also in support of this
> type of approach.  We would like to see some community discussion
> around what are the key areas/priorities that the community would like
> to see discussed at Dev Days.  Your topics below look like a good
> start. The SACM list might be a better venue than the OVAL list for
> this discussion.  For each area we should focus the discussion around
> developing objectives for each session.  The sessions can be time boxed
> based on what would be a reasonable amount of time to accomplish each
> objective.  For example if continuous monitoring is a priority and
> collectively it takes 3 days to work through all the objectives, I see
> no problem with that.  We can also keep a few sessions "on deck" if all
> the objectives are reached and we complete all the scheduled sessions
> early.
>
>
>
>       Thoughts?
>
>
>
>       Sincerely,
>
>
>
>       David Waltermire
>
>       SCAP Architect
>
>       Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer
>       I see this appears to follow a path we have discussed in the past
> as the way not to hold a Dev Days event.  We have been trying to get
> away from 'Death by Powerpoint' and back to the type of event we held
> years ago when we were highly productive.  In the past we had a topic
> to be discussed and a time box to work within.  That allowed us to have
> very active brainstorming sessions in a high bandwidth environment.
>
>
>
> time and all who are attending are investing a great deal of time and
> money to be there.  We should not  be spending a great deal of time
> reeducating everyone when we could be focused on advancing needed
> efforts.
>
>
>
>       The type of approach to a Dev Days event was discussed at the
> last Summer Dev Days.  I have seen the following work quite well in
> other efforts.
>
>       3.      Focused brainstorming time should be established for
> certain areas that need real work by the community
>       4.      Efforts to be discussed should be based on needs of the
> security automation space to move existing efforts to completion.
>
>       For example:
>
>
>
>       Continuous monitoring is a major direction the efforts are
> becoming involved with. There are going to be things we need to do as a
> security automation community to be able to accomplish what is listed
> in the CAESARS FE.  There are interfaces that need to be worked and
> established.  That is one area that is not listed below.  CM will have
> a major impact on all of us in the next couple years and it is being
> ignored.  We can't keep trying to solve what has already been solved.
> We need to address the needed interface development now. This is an
> effort that could take nearly a whole day by itself.
>
>
>
>       Operationally we have a real need to be able to deliver SCAP
> content internally within an organization. Today the SCAP vendors
> cannot share a single local site security policy (XCCDF + OVAL + CPE
> +.) without the site staff having to go to each of the individual
> products and figuring out how to inject that new or updated policy into
> that products delivery mechanisms.  That is limiting sites from wanting
> to buy multiple focused SCAP products since they are such a pain to
> manage from a content perspective.  It is easier to buy from one vendor
> that has a single means for distributing content than it is to deal
> with the management issues that having multiple SCAP products presents.
> We need to have at least an entire 1/2 a day on the development of a
> Content Repository specification.
>
>
>
> value that is being underutilized and under implemented because of the
> limitations of how it addresses uses in an enterprise environment.
> People don't need security automation to do things on/for a single
> host.  They need security automation to focus on the enterprise issues
> that reduce their costs and improve their efficiencies.  OCIL is
> failing in the enterprise and we all understand that.  We need to
> address developing a definitive solution for incorporating OCIL into
> the enterprise and that means into the existing specifications.
> Scheduling and tracking are key to it's success.  We need to make that
> happen.  This too needs a focused brainstorming time box to discuss
> options.
>
>
>
>       I am really disappointed that Remediation is not on the list
> below.  Yes, last Summer Dev Days, the time spent on Remediation was
> wasted time but that does not mean we should ignore it and not try to
> make some real progress.  As far as I am concerned we need to reboot
> the remediation effort.  We cannot keep being the set of specifications
> / tools that act as the little boy crying "Wolf" in the night.  We need
> difference in organizational security postures.  But today we think it
> is too hard so we don't try ?  I think we need a couple hours to
> needed.  For the vendors here, we have all gone through the Cyberscope
> goat rope, delivering limited capabilities to specific data call
> requirements of the Federal Agencies.  The initial effort was a mess,
> did little more than prove it was possible and cause the vendor
> community a great deal of thrashing to put a kludgey 'solution' in
> place.  Reality is all our customers need roll up reporting and an
> infrastructure that supports it.  A data call should not be special to
> anyone other than the agencies responding. The tools should be able to
> select the types of data needed and deliver that on a scheduled basis
> automatically.    Enterprise Reporting pertains to commercial as well
> as Federal customers.  We need to focus some time on what that would
> look like using the ARF and ASR as the foundational pieces.  But there
> are missing pieces..  We need this discussed.
>
>
>
> more critical issues our customers are facing now or will be facing in
> the very short term.  Status presentations are not interesting to those
> active in the efforts.  Let's try to do those before we get to Bedford
> so we can real make some progress while we are all in the same room.
> This is always a big event for the 'consensus of the willing' that
> assemble and driven to see security automation make a difference.
> Let's see if we can have an event that, when we all walk out the last
> day, we all feel that every minute was well spent and moves us forward.
>
>
>
>       Thanks.
>
>
>
>       Kent Landfield
>       Reply-To: "OVAL Developer List (Closed Public Discussion)" <OVAL-
> [email-masked]>
>       To: "[email-masked]" <OVAL-DEVELOPER-
> [email-masked]>
>       Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer
>               We hope to have the registration site up next week.  The
> event will be during the week of July 9 - starting Monday at 10:00 AM
>               Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation
>               Subject: [OVAL-DEVELOPER-LIST] Security Automation
> event will be held during the week of July 9, 2012 at MITRE's facility
> in Bedford, MA.
>
>
>
>               Details to follow.
>
>
>
>               Regards,
>
>                   Steve
>
>
>
> [email-masked] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY
> of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-
> [email-masked].
>
> [email-masked] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY
> of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-
> [email-masked].
>
> [email-masked] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY
> of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-
> [email-masked].

---

From: Gunnar Engelbach <[email-masked]>
Date: Fri, 18 May 2012 11:16:37 -0400

There are limitations in encoding requests using an HTTP GET, such as a 
maximum URI length, but most webservers support 8KB URLs, so the 
drawback to using a GET is the ability to send a structured request or 
to embed binary data.  Most of the time I think you'll find that a query 
can be parameterized into a URL, which makes it a nice lightweight 
request format, but if not REST also allows for the use of a POST where 
the content structure is arbitrary and the typical limit is more like 2GB.

A consideration for using JSON is that JSON data is actually code 
objects that are evaluated on the receiving end by executing them, so 
they are a potential attack vector.  Using JSON means either having 
complete trust in the sender of the JSON objects or having complete 
trust in your ability to detect attack code on the receiving end.

--gun

On 5/18/2012 10:24 AM, Waltermire, David A. wrote:
>> From:<Kinney>, Michael A<[email-masked]>
>> To: David Waltermire<[email-masked]>, SCAP-DEV<SCAP-
>> [email-masked]>, "[email-masked]"<[email-masked]>
>>        From:<Boczenowski>, Steve<[email-masked]>
>>        Reply-To: "OVAL Developer List (Closed Public Discussion)"<OVAL-
>>        To: "[email-masked]"<OVAL-DEVELOPER-
>> [email-masked]>

---

From: Gunnar Engelbach <[email-masked]>
Date: Fri, 18 May 2012 12:46:56 -0400

On 5/18/2012 12:41 PM, Kurt Seifried wrote:
> On 05/18/2012 09:16 AM, Gunnar Engelbach wrote:
>>
>> There are limitations in encoding requests using an HTTP GET, such
>> as a maximum URI length, but most webservers support 8KB URLs, so
>> the drawback to using a GET is the ability to send a structured
>> request or to embed binary data.  Most of the time I think you'll
>> find that a query can be parameterized into a URL, which makes it a
>> nice lightweight request format, but if not REST also allows for
>> the use of a POST where the content structure is arbitrary and the
>> typical limit is more like 2GB.
>>
>>
>> objects that are evaluated on the receiving end by executing them,
>> so they are a potential attack vector.  Using JSON means either
>> having complete trust in the sender of the JSON objects or having
>> complete trust in your ability to detect attack code on the
>> receiving end.
>>
>>
>> --gun
>
> This is not true. Perhaps you are thinking of JavaScript and using the
> eval() method to parse the JSON data? Which you shouldn't be doing.
> Pretty much all other JSON decoders don't do anything as remotely
> crazy as running the input straight through eval().

Thanks.  That shows you how limited my exposure to JSON has been thus far.

>
> JSON simply allows you to encode numbers, strings, booleans, arrays,
> objects (key:value pairs) and null. Nothing magic. Unless you do
> something crazy like shove the untrusted input straight through eval()
> or blindly use the input without some minimal filtering (e.g. escaping
> it for SQL queries) you should be fine.
>
>
> - --
> iQIcBAEBAgAGBQJPtnuxAAoJEBYNRVNeJnmTATMP/RNrGLnnHx41e/Z2e7uQVTcM
> p0bfBg8U7KQhE9c6cgwt9A+0CZ5RsihYSfEYgf3ryXZ8R9iZPbUO+fgEWZbS/G7b
> wXJI9PMtwdOQPjH6+yq9ET/3usDKTLHZ4c0wJrpdeGb4HaKJG89fmZuOMimMfzxr
> s7f6+sQLND5r5mQ+Y6mqvC//YCcm9BSkq8G5l/Ra5sADadCuPro2NI5pZI5Et/cz
> lQCewnk2EhTZQr8ne12dUxFs22tyNafyYkkCLUIi4bPVuovqoe2qCpK3CL99mMsR
> bfmCsiCDUXq87SuEIu/0si43eIgeMcnvI1bgPTWyuXuRIf4S/wz3zgWJhD4oiUvb
> cGL4Fb6HvpegRa5mHVUhd7pnlo/RzoCO5K1XHnUHg+0qQwFqUx75mcxUijJxErOQ
> eMP/7qBFfs6kdCNB+Uut2vtfGhbzoQ1qjTkTDVt1bBjP6KAX1nUzCZZfV1WpoN4d
> B6fPTw83PyPotvKI8as9ZIk5TO3BPuEvuggQjR28h8pwX2D3KWQtLdi6QEavFD0P
> 499h3u1nwnSVm922U/BpNMvwYnHDY/Q6KCsUzIoCRmMo8CXoGTyjWhEMocjZVmlX
> pmR80rmxyzEiK9aLTZb9IO8XhM9oPyALF57m8tYbupN+NlSiyCAvIbcciK/GE9qz
> hDNlxW1RQB51+Jv5M/2P
> =lDW+

---

From: Gunnar Engelbach <[email-masked]>
Date: Fri, 18 May 2012 13:03:50 -0400

Dave,

It sounds like you are trying to solve two separate problems here.

The first is the ability to retrieve content from a repository, the 
second is the ability to locate repositories.

I'm not seeing enough of an overlap between these two sets to need to 
address them in the same standard.

As far as modeling discovery on DNS, I'm not sold, but that could just 
be a lack of understanding on my part -- and I still haven't had time to 
read your draft spec.

But it sounds like a chicken-and-egg problem.  In order to locate a 
repository you first have to know something about the repository -- the 
publisher's namespace URI from your example.

In my experience discovery is more likely to be based on search 
criteria:  affected platform, guidance source, supported languages, 
content formats, regulation applicability (SOX, HIPAA, etc), and so on. 
  That's more like a searchable registry -- I don't see where DNS-style 
name resolution comes into it.

--gun

On 5/18/2012 8:42 AM, Waltermire, David A. wrote:
> iQIcBAEBAgAGBQJPtbFIAAoJEBYNRVNeJnmTuwsQANiygjm9i8AAjiwXMWb3K/RZ
> uIcqM+kbO18cFIWce7p5njzcmRx2eeFFpmMfMTWPrfs7AMjSRjpGy9DNQ9wvlIyR
> GVgwpeWiIK3cZJza3YFEhUfpng3Ivek3kp3nKDgTgm7wBATi0NrRMG6/QRPxxJnK
> MXPjON4aenqInIFxRGoDqplR7e6g6RXuaD4B376f+LC0R7j8lWUK4ug/GTkBPkXf
> LfDuY1Q4u9ctB+tXWQyCwRe4sQ2Gd+PXYzyDENa9kd3e5P/6LTWn3spZQvfEa0Ew
> xQj8YB5VbsyT39GvtlJOV0cJ35HOZBGhwtqwa3vJ6xE3sWCNuJdWqvHr7T8A0Qus
> u4VO6Gc6S6Nrq6DbU9tn11jMoDwwP1wtqFx+l9bhhzSw5VNKVnkTq7/Q0fXd9Q2r
> GfPp0ZplyL4lRfhfglt/dKbGPOoiOhuFXKeJw9MVQRU0ZHRKxnpw+DeFoBCQXpUH
> TdHBg7gu37yB/dAxs63CZKlC1GDi8nXNZ4+myTDDsnqogzbkP61p3acoYFuunLGK
> +JMj0f3OktzZRFqylUbrqw/ONHO5zvZOjZp6pQAikG9Vvn89PsmuXHZvbNJRlaqi
> oiTDzeONz3yyvwjEYg5J1i11e+tzM6x248ulclh+82CwhKL9G1AotFIi803iXrbv
> XCldnHSPS6O7qeRTgMtL
> =QJsL

---

From: "Panos Kampanakis" <[email-masked]>
Date: Fri, 18 May 2012 13:31:34 -0400

Are you saying that the scope of the draft should only be to 

- define the challenges to be addressed
- introduce the Metadata Model
- address the Federation or repository discovery problem

Panos

-----Original Message-----
From: Kurt Seifried [mailto:[email-masked]] 
Sent: Friday, May 18, 2012 12:26 PM
To: Panos Kampanakis
Cc: 'Waltermire, David A.'; SCAP-DEV; [email-masked]
Subject: Re: [scap-dev] [sacm] Request for participants - Content Repository

* PGP Signed by an unknown key

On 05/17/2012 04:29 PM, Panos Kampanakis wrote:
> - Also, should the data Exchange mechanism be part of this draft?
> For example HTTP/TLS messages etc (as in MILE's rfc6546) or JSON, 
> SOAP, REST as were suggested in SACM's alias before?

What if I want to deliver it over IPSec? or using a push mechanism? or
offline via encrypted USB key (not all hosts have connectivity)? Or I want
to use a content delivery network (such as Akamai, or my own based on
something like pulp) because I have 10,000 hosts? What if I have hosts that
are not allowed to talk SSL (because I need to monitor the network for
nefarious activity)?

Defining the data delivery method for what is essentially a file
specification strikes me as... bizarre. Again shouldn't this be left up to
the end implementation?

If you provide a REST/SOAP service (effectively something that talks
HTTP) it's not like we don't have ways to secure it that are appropriate for
pretty much any use case you can think of. Again, defining this in the spec
means more over head, and incompatibility with anyone not doing it exactly
that way. Leaving it up to the end implementation makes way more sense as
different people have different AIC/etc requirements, and again in this
problem space we have many well understood solutions.

--

* Unknown Key
* 0x5E267993(L)

---

From: Gunnar Engelbach <[email-masked]>
Date: Fri, 18 May 2012 13:50:32 -0400

> it for SQL queries) you should be fine.

So used that way, as a text document that groups name/value pairs, what 
would be the reason for using JSON over XML?

---

From: "Panos Kampanakis" <[email-masked]>
Date: Fri, 18 May 2012 13:55:58 -0400

I see now. And agree.

-----Original Message-----
From: Kurt Seifried [mailto:[email-masked]] 
Sent: Friday, May 18, 2012 1:54 PM
To: Panos Kampanakis
Cc: 'Waltermire, David A.'; 'SCAP-DEV'; [email-masked]
Subject: Re: [scap-dev] [sacm] Request for participants - Content Repository

On 05/18/2012 11:31 AM, Panos Kampanakis wrote:
> - define the challenges to be addressed - introduce the Metadata Model 

No. I am saying that defining something "We will use SOAP/REST with XML/JSON
(pick some combination thereof, or something else, whatever)"
make sense. Defining "you MUST deliver this over SSL encrypted HTTP"
makes no sense because for one thing I know there are sites that can't use
SSL, or use something like IPSec instead, or need an offline manner that
works well, or need a push method, and so on.

As I understand this problem it's basically a file delivery/information
delivery issue. So file format, etc. Defining how the file is delivered, how
authentication is done, etc, seems outside the scope of this (and there are
lots of great existing solutions). I suspect these issues should be left up
to implementation/vendors/etc to address the specific use cases.

E.g. if you guys choose to put authentication in the spec will you
support:

username/password (what auth backend do you support/use? something
internal?)
OTP?
Kerberos?
NTLM?
LDAP?
X.509 client certs?
Combinations of the above (e.g. an X.509 cert + OTP is required)?

For discovery, what about LDAP? DNS? UPnP? Bonjour? How do you prevent a bad
guy from spoofing/etc? How do you authenticate the server to the client (to
ensure clients connect to a legit server)?

My fear is that any specification in these lower level layers will cause
incompatibilities and overhead in the devel/spec/building process that don't
actually create any real benefit. All of these issues have a wide variety of
solutions appropriate for various use cases, I think it should be left to
the end vendor/user to decide appropriately.

* Unknown Key
* 0x5E267993(L)

---

From: Kurt Seifried <[email-masked]>
Date: Fri, 18 May 2012 10:25:46 -0600

On 05/17/2012 04:29 PM, Panos Kampanakis wrote:
> spec. But XML has its own mechanisms to provide them. Thus the
> content itself can provide Integrity and Confidentiality. I am not
> sure if the spec should have Integrity and Confidentiality as
> required features.
> 
> 
> 
> For example HTTP/TLS messages etc (as in MILE’s rfc6546) or JSON,
> SOAP, REST as were suggested in SACM’s alias before?

What if I want to deliver it over IPSec? or using a push mechanism? or
offline via encrypted USB key (not all hosts have connectivity)? Or I
want to use a content delivery network (such as Akamai, or my own
based on something like pulp) because I have 10,000 hosts? What if I
have hosts that are not allowed to talk SSL (because I need to monitor
the network for nefarious activity)?

Defining the data delivery method for what is essentially a file
specification strikes me as... bizarre. Again shouldn't this be left
up to the end implementation?

If you provide a REST/SOAP service (effectively something that talks
HTTP) it's not like we don't have ways to secure it that are
appropriate for pretty much any use case you can think of. Again,
defining this in the spec means more over head, and incompatibility
with anyone not doing it exactly that way. Leaving it up to the end
implementation makes way more sense as different people have different
AIC/etc requirements, and again in this problem space we have many
well understood solutions.

- --

---

From: Kurt Seifried <[email-masked]>
Date: Fri, 18 May 2012 10:41:21 -0600

- --

---

From: Kurt Seifried <[email-masked]>
Date: Fri, 18 May 2012 11:54:24 -0600

On 05/18/2012 11:31 AM, Panos Kampanakis wrote:
> - define the challenges to be addressed - introduce the Metadata
> Model - address the Federation or repository discovery problem
> 
> Panos

No. I am saying that defining something "We will use SOAP/REST with
XML/JSON (pick some combination thereof, or something else, whatever)"
make sense. Defining "you MUST deliver this over SSL encrypted HTTP"
makes no sense because for one thing I know there are sites that can't
use SSL, or use something like IPSec instead, or need an offline
manner that works well, or need a push method, and so on.

As I understand this problem it's basically a file
delivery/information delivery issue. So file format, etc. Defining how
the file is delivered, how authentication is done, etc, seems outside
the scope of this (and there are lots of great existing solutions). I
suspect these issues should be left up to implementation/vendors/etc
to address the specific use cases.

For discovery, what about LDAP? DNS? UPnP? Bonjour? How do you prevent
a bad guy from spoofing/etc? How do you authenticate the server to the
client (to ensure clients connect to a legit server)?

My fear is that any specification in these lower level layers will
cause incompatibilities and overhead in the devel/spec/building
process that don't actually create any real benefit. All of these
issues have a wide variety of solutions appropriate for various use
cases, I think it should be left to the end vendor/user to decide
appropriately.

- --

---

From: Gunnar Engelbach <[email-masked]>
Date: Fri, 18 May 2012 14:47:40 -0400

On 5/18/2012 1:55 PM, Kurt Seifried wrote:
> On 05/18/2012 11:50 AM, Gunnar Engelbach wrote:
>>> So used that way, as a text document that groups name/value
>>> pairs, what would be the reason for using JSON over XML?
>
> Simplicity for one =). But in this case if everything is already XML
> than XML is probably a better idea.

I'd like to ignore that the SCAP world is already neck-deep in XML as 
far as this is concerned for the simple reason that I'd like to allow 
for the possibility that there might be repository/client relationships 
outside of the SCAP world.  There's no reason, for example, that a 
repository can't also be used to serve up prose guides as PDF documents 
or checklists as spreadsheets.

I'm going to create another opportunity to express my JSON ignorance, 
but it's really just nested groupings of name/value pairs, isn't it? 
XML requires a bit more markup to be legal, but it can be that simple as 
well.

Does JSON support the equivalent of an XML schema that can be used to 
communicate the structure of the document?

I can list many positive reasons for using XML but I'm not going to 
champion it at this point:  I'd like to see a good description of the 
problem space and more information on possible alternatives before 
casting a vote, so thanks beforehand to anybody who presents good 
arguments for the consideration of any alternative.

--gun

> iQIcBAEBAgAGBQJPto0ZAAoJEBYNRVNeJnmTNK4P/3KFkGmffbTzKgL/E7CU/BGb
> nTu+BHmoopLH2VaCPU/NmdbIPBxEiK6lvkAP15Tgp3d0LkToO8UU+kljdlo819OY
> p7hBxyb2SNnahuva83vaB5PHhqeUi7tiWec/nY7q27E0MGdl47faHgy/xdmOKTX7
> gzgmmrW4e+Z234T9k68yfiROzPZ+GcG55j2r3JOa4I5lDNRsKY4WIIQuSt0gHp39
> 1Vm9TfHgjvtm0aX9YSS8/m7dbt54Q+a4NFTtAB4qYqsqmLpGM5pzXDK5k81Y1kv6
> GGBIJDApvB7sDHcDToas6plIsTcu+loIJiu3lNruIA1HR9va0py1zUlwJlJ0yGL9
> 9m+f4y+PKO3eoCVZjeypn2C3/XXlEevk5DmIjIsTo2VFhDfkkKqj8AG0dg2Omwt8
> nvMIvMJ5RU9AWnNMkGgfRdmcxVWGws1WTaIoU8sPG7LoXa3jlKvV2hGtB9Tq9uIN
> hPWYrfyU6T48D5W5VvLNNw3d+DfCqpmw0toXr0JVdvrtLoCL4eB9li9YN+Th6o2S
> Hqc7bl/ZXf42wzCFyD3uEkLsqLF7dLbKJyrEfpBwMdPAl2bWsz01g1sSXRcADs58
> DcZn9ygoPNzChlGuQVvnfVTG1w2AvDqILj+UBHmfn5qDkFnKbeNFlVwz8bbIw44W
> OvM93OHktP45xXwavRPa
> =i7NF

---

From: "Waltermire, David A." <[email-masked]>
Date: Mon, 21 May 2012 10:41:33 -0400

My comments below, marked [DAW]

Sincerely,
Dave

-----Original Message-----
From: Kurt Seifried [mailto:[email-masked]] 
Sent: Friday, May 18, 2012 12:26 PM
To: Panos Kampanakis
Cc: Waltermire, David A.; SCAP-DEV; [email-masked]
Subject: Re: [scap-dev] [sacm] Request for participants - Content Repository Specification Development

> SOAP, REST as were suggested in SACM's alias before?

What if I want to deliver it over IPSec? or using a push mechanism? or offline via encrypted USB key (not all hosts have connectivity)? Or I want to use a content delivery network (such as Akamai, or my own based on something like pulp) because I have 10,000 hosts? What if I have hosts that are not allowed to talk SSL (because I need to monitor the network for nefarious activity)?

[DAW: This is a good argument to separate the definition of the transport from the interface definitions. I could go either way on this as well.  If we want a high degree of interoperability, we will likely want to define a single transport as mandatory-to-implement (MTI).  This doesn't mean that it has to be the only available transport.  I just means that it is the default one that can be expected from any implementation.  An implementation could support additional transports to address your use cases.  These transports could be written as separate drafts.

As for the MTI transport, if we want a high degree of interoperability here, (which I think we do), it may make sense to include the MTI transport in the main I/D, but include text stating that others are allowed as well.  Thoughts]

Defining the data delivery method for what is essentially a file specification strikes me as... bizarre. Again shouldn't this be left up to the end implementation?

[DAW: If security automation content is a file based problem, then why is there any demand for a content repository at all?  Basic file distribution technologies (e.g. HTTP, FTP, Atom, etc.) should be used instead.

Where I see the demand coming from is that content authors and content users are generally only interested in part of the file.  They want the useful parts of the file that matter to them (e.g. OVAL definitions, OCIL questionnaires), but not all the rest of the document. This means that file distribution mechanisms are not enough for their needs.  What I am hearing from talking with content users is that they want a content repository capability that decomposes and works with content components (e.g. OVAL definitions, XCCDF Rules, NVD CVE records, etc) not the entire document.  They ultimately want to be able to compose together components sourced from many files to produce a new document.  If we want this kind of implementation to look the same from a client perspective, then we need to standardize the interfaces and transport(s) used at minimum.]

If you provide a REST/SOAP service (effectively something that talks
HTTP) it's not like we don't have ways to secure it that are appropriate for pretty much any use case you can think of. Again, defining this in the spec means more over head, and incompatibility with anyone not doing it exactly that way. Leaving it up to the end implementation makes way more sense as different people have different AIC/etc requirements, and again in this problem space we have many well understood solutions.

[DAW: I can see your point. As part of this process, we need to identify security requirements and recommendations. My concern is mostly around interoperability. Which way we go depends on how much interoperability we want to have between ALL conformant implementations. This decision will set the minimum threshold required by all implementations and must allow for alternatives. If we want secure, interoperable communications, then we will need to make some choices as to what is required vs. recommended.]

- --

---

From: "Waltermire, David A." <[email-masked]>
Date: Mon, 21 May 2012 10:41:34 -0400

Sincerely,
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gunnar Engelbach
Sent: Friday, May 18, 2012 1:04 PM
Cc: SCAP-DEV; [email-masked]
Subject: Re: [sacm] [scap-dev] Request for participants - Content Repository Specification Development

Dave,

The first is the ability to retrieve content from a repository, the second is the ability to locate repositories.

I'm not seeing enough of an overlap between these two sets to need to address them in the same standard.

[DAW: We would be introducing significant complexity into the client if we separate these concerns.  By mirroring the DNS approach for repository federation, we can keep things simple on the client side.  In my view, both of these operations would be handled by the local content repository associated with the client.  Just like in DNS, the local content repository server will resolve the location of each content repository based on the content identifier namespace using the corresponding SRV record.  It will then dispatch a request to these content repositories to retrieve the content.  It can optionally cache the content and then provide it back to the client.  This entire process is transparent to the client.

For example, a configuration scanning agent is ordered by the scanning manager to perform a scan on a repeating interval using a set of content.  The set of content required is a list of OVAL definition IDs developed by a third party vendor hosted in the third party vendor's content repository. The agent has been preconfigured to point to the local content repository to which it sends a request to for the content. The local repository looks up the namespace associated with the third party content IDs in DNS retrieving the SRV record for the third party content repository. It dispatches a request for the content to the third party repository and retrieves the content, caching it, and providing it to the client.]

[DAW: What I am suggesting is not "discovery" per se, it is resolution using DNS SRV records.  This is the general purpose of the SRV mechanism.]

[DAW: My example pre-supposes that the content IDs have already been selected.  Meaning that the organization performing the scan pre-selected content from the third party registry.  This introduces a third problem that needs to be solved that is a discovery style problem.  For the web, we have web-based search engines that index content from a variety of sources and then provide persistent pointers to the location of the content.  We probably need something like this too, but that is a concept that more than likely needs to be addressed by one or more additional specifications.

Initially, organizations are going to seek content from sources that act as authorities for their organization or that are trusted.  Discovery matters at the point where digital policy is constructed.  In this scenario, if a content repository supports simple standardized query capabilities, we probably have a workable solution for the short-term. In my example above, the scanning manager is responsible for many different agents on many different hosts.  The system user would create scanning configurations based on content they have pre-selected and these configurations would then get propagated to the individual scanners.  The pre-selection could be the result of querying a list of authoritative and trusted repositories.  This usage pattern also applies to single host and agentless approaches.]

--gun

---

From: Michael Hammer <[email-masked]>
Date: Mon, 21 May 2012 16:59:28 +0000

Rather than having a lot of polling, could you use a Subscribe-Notify type
of framework, 
where notices of new information or updates get distributed?

Polling seems like it could get chatty, and raises the question of how
often.

Mike

-----Original Message-----
Sent: Monday, May 21, 2012 10:42 AM
To: Gunnar Engelbach

Sincerely,
Dave

-----Original Message-----

Dave,

The first is the ability to retrieve content from a repository, the second
is the ability to locate repositories.

[DAW: We would be introducing significant complexity into the client if we
separate these concerns.  By mirroring the DNS approach for repository
federation, we can keep things simple on the client side.  In my view, both
of these operations would be handled by the local content repository
associated with the client.  Just like in DNS, the local content repository
server will resolve the location of each content repository based on the
content identifier namespace using the corresponding SRV record.  It will
then dispatch a request to these content repositories to retrieve the
content.  It can optionally cache the content and then provide it back to
the client.  This entire process is transparent to the client.

For example, a configuration scanning agent is ordered by the scanning
manager to perform a scan on a repeating interval using a set of content.
The set of content required is a list of OVAL definition IDs developed by a
third party vendor hosted in the third party vendor's content repository.
The agent has been preconfigured to point to the local content repository to
which it sends a request to for the content. The local repository looks up
the namespace associated with the third party content IDs in DNS retrieving
the SRV record for the third party content repository. It dispatches a
request for the content to the third party repository and retrieves the
content, caching it, and providing it to the client.]

As far as modeling discovery on DNS, I'm not sold, but that could just be a
lack of understanding on my part -- and I still haven't had time to read
your draft spec.

[DAW: What I am suggesting is not "discovery" per se, it is resolution using
DNS SRV records.  This is the general purpose of the SRV mechanism.]

In my experience discovery is more likely to be based on search
criteria:  affected platform, guidance source, supported languages, content
formats, regulation applicability (SOX, HIPAA, etc), and so on.
  That's more like a searchable registry -- I don't see where DNS-style name
resolution comes into it.

[DAW: My example pre-supposes that the content IDs have already been
selected.  Meaning that the organization performing the scan pre-selected
content from the third party registry.  This introduces a third problem that
needs to be solved that is a discovery style problem.  For the web, we have
web-based search engines that index content from a variety of sources and
then provide persistent pointers to the location of the content.  We
probably need something like this too, but that is a concept that more than
likely needs to be addressed by one or more additional specifications.

Initially, organizations are going to seek content from sources that act as
authorities for their organization or that are trusted.  Discovery matters
at the point where digital policy is constructed.  In this scenario, if a
content repository supports simple standardized query capabilities, we
probably have a workable solution for the short-term. In my example above,
the scanning manager is responsible for many different agents on many
different hosts.  The system user would create scanning configurations based
on content they have pre-selected and these configurations would then get
propagated to the individual scanners.  The pre-selection could be the
result of querying a list of authoritative and trusted repositories.  This
usage pattern also applies to single host and agentless approaches.]

--gun

Waltermire, David A.
> Repository Specification Development
>
on.
>> key distribution yet.  It would be if we could use DNS or some other 
> registry. Even for a central registry, I feel we aren't there yet. 
> Central repository or a registry would mean getting into operational 
> aspects, who'll own, manage, control etc., So, limiting it to 
> organizational repositories and content providers repository is good 
> in my view.]
>
> [DAW2: This is why I am advocating for a federated system.  With the 
> right approach, we can avoid having to stand up a single central 
> registry and all the operational and logistical aspects involved. 
> Using the DNS SRV approach below, DNS essentially becomes the 
> registry.  Using DNS, every organization that produces content is able 
> to point to the authoritative content repositories that they use to 
> host their content. They can create as many namespaces as needed, by 
> using sub-domains within their own domain(s). A SRV record would be 
> associated with each sub-domain in this case.]
>
> As far as supporting repo resolution, I am recommending a namespaced
content identifier approach based on DNS names.  Many of the security
automation identifiers have reverse DNS names incorporated into them.  For
those that done, simple DNS namespace qualification would provide the same
effect.  In either case, this info can be used to lookup the content
repository that is authoritative for the content referenced by the ID.  This
can be handled using a DNS SRV record (RFC2783).  We would need to get an
IANA allocation for this (RFC6335).  This approach avoids having to create a
root server infrastructure for content repositories.
> completely, will anyway pose a question. If one content repository 
> were to host a content authored by someone else and the namespace 
> wasn't modified, may be for IP reasons. DNS namespace qualification 
> would not work if I want to pick the content from this repository 
> instead of the original author. Not sure if I am making sense :) ]
>
> [DAW2: I am modeling this approach after DNS.  There are authoritative
content servers that originate content.  The DNS SRV records would be mapped
to the DNS namespaces hosted by a given authoritative content server.  This
is an analog to domains hosted by an authoritative DNS server.  Here is a
basic communication flow:
>    d) Dispatch a request to the foreign authoritative content repository
based on the SRV record to retrieve the content
> This approach allows content for a given namespace to be managed by a
single authoritative content repository.  If a third party is hosting
content for another (e.g. repository-as-a-service), then the DNS SRV record
for the content's ID namespace would point to the 3rd party hosted
repository.
>
> Access to local cache can (and probably should) be limited to IPs 
> within an organization or thru the use of access controls to prevent 
> leakage of cached content.]
>
> I would classify content rights management as well beyond the scope of
this project (you know have to basically build a CA type entity, handle cert
revocation for expired clients, etc, etc, etc.) and something to be left up
to the end vendor/customer that actually wants this. Building in DRM is a
huge amount of effort and I suspect it would mostly be wasted. Any content
>
> TLDR: Please, please don't do this, it'll be a huge time/effort sink and
not worth it. Anyone that wants to sell this kind of thing already has
systems capable of delivering files and managing access/rights to them.
>
> [DAW: Points well taken.  I am interested in other thoughts on how 
> best to address this.  What I was recommending was looking more 
> towards service authentication and less towards DRM. Maybe we don't 
> address this in the first pass.  Thoughts?]
>
> [CHA: Access control is definitely a requirement for organizational
content server as well as content providers repository. Once the service is
authenticated, it should be left to the implementers to define/implement
their own access rights. Because, an entity communicating with the
repository will not see any difference in the behavior.

---

From: "Waltermire, David A." <[email-masked]>
Date: Mon, 21 May 2012 13:09:08 -0400

That is also an option.  It could be supported in addition to a polling method also.  The challenge with pub-sub is that content servers would need to register with other content servers to make this work.  The DNS model doesn't require any prior knowledge on behalf of the content servers and it is essentially stateless. A pub-sub model would require a lot of state tracking.

Sincerely,
Dave

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Monday, May 21, 2012 12:59 PM
To: Waltermire, David A.; [email-masked]
Cc: SCAP-DEV; [email-masked]
Subject: RE: [sacm] [scap-dev] Request for participants - Content Repository Specification Development

Mike

-----Original Message-----

Sincerely,
Dave

-----Original Message-----

Dave,

--gun

Waltermire, David A.
on.

---

From: Michael Hammer <[email-masked]>
Date: Mon, 21 May 2012 17:17:43 +0000

It would be possible for centralized star, with reciprocal subscriptions.
Sources publish, and central devise broadcasts to subscribers.
Filters could also be applied.

Guess it depends on whether you want a pull or push model.
May depend on how often you see data needing to be transferred.
And whether an intra-poll delay is acceptable or not.

Mike

-----Original Message-----
From: Waltermire, David A. [mailto:[email-masked]] 
Sent: Monday, May 21, 2012 1:09 PM
To: Michael Hammer; [email-masked]
Cc: SCAP-DEV; [email-masked]
Subject: RE: [sacm] [scap-dev] Request for participants - Content Repository

That is also an option.  It could be supported in addition to a polling
method also.  The challenge with pub-sub is that content servers would need
to register with other content servers to make this work.  The DNS model
doesn't require any prior knowledge on behalf of the content servers and it
is essentially stateless. A pub-sub model would require a lot of state
tracking.

Sincerely,
Dave

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Monday, May 21, 2012 12:59 PM
To: Waltermire, David A.; [email-masked]
Cc: SCAP-DEV; [email-masked]
Subject: RE: [sacm] [scap-dev] Request for participants - Content Repository

Rather than having a lot of polling, could you use a Subscribe-Notify type
of framework, where notices of new information or updates get distributed?

Mike

-----Original Message-----

Sincerely,
Dave

-----Original Message-----

Dave,

--gun

Waltermire, David A.
> and so
on.
> (although
content servers that originate content.  The DNS SRV records would be mapped
to the DNS namespaces hosted by a given authoritative content server.  This
is an analog to domains hosted by an authoritative DNS server.  Here is a
basic communication flow:
>    b) If the namespace is a foreign namespace, check if the content is 
> in
the local cache.
> RPM
> and

---

From: "Waltermire, David A." <[email-masked]>
Date: Mon, 21 May 2012 13:25:03 -0400

The centralized star is interesting, but I am not sure we want to get into the management concerns around who would maintain the "hub".  My preference has been for loose federation with distributed management of the nodes.

Any other thoughts?

Sincerely,
Dave

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Monday, May 21, 2012 1:18 PM
To: Waltermire, David A.; [email-masked]
Cc: SCAP-DEV; [email-masked]
Subject: RE: [sacm] [scap-dev] Request for participants - Content Repository Specification Development

Mike

-----Original Message-----
From: Waltermire, David A. [mailto:[email-masked]]
Sent: Monday, May 21, 2012 1:09 PM
To: Michael Hammer; [email-masked]
Cc: SCAP-DEV; [email-masked]
Subject: RE: [sacm] [scap-dev] Request for participants - Content Repository

Sincerely,
Dave

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Monday, May 21, 2012 12:59 PM
To: Waltermire, David A.; [email-masked]
Cc: SCAP-DEV; [email-masked]
Subject: RE: [sacm] [scap-dev] Request for participants - Content Repository

Mike

-----Original Message-----

Sincerely,
Dave

-----Original Message-----

Dave,

--gun

Waltermire, David A.
on.
the local cache.

---

From: Sean Turner <[email-masked]>
Date: Wed, 23 May 2012 08:38:53 -0400

Kent,

Technically, authors can specify really just about anything they want - 
but they're going to have to defend it.  Some defenses are easier than 
others.  At least one person said they'd have to ask why SOAP, and that 
they'd be skeptical of any answer that didn't involve interoperating 
with something written a long time ago.

I asked around some to verify that my impression wasn't just mine and 
confirmed that SOAP has pretty much fallen out of favor while REST seems 
to be where it's at.  You might ask why - well SOAP is XML based and XML 
has also fallen out of favor.  As Kathleen pointed out, all the cool 
kids are doing JSON ;)  For some, REST doesn't rely on XML so it's just 
better.

Hope this helps,

spt

PS - But, if JSON ends up being used you're going to have to wait for a 
security solution.

On 5/14/12 3:39 PM, [email-masked] wrote:
> Sean – please do chime in.
>
> My .02:   When MILE was INCH, the WG had thought SOAP and BEEP were good
> solutions to fit the protocol (so the WG can drive what they think is
> needed).  But the IETF saw that the direction at the time was HTTPS,
> which would seem to agree with the statement below.  There really were
> not many BEEP implementations, so it didn’t seem practical even if the
> protocol design was a better fit.  REST wasn’t popular then, so we also
> took the approach to separate out the protocol from the binding to allow
> for changes later (add new bindings).  With this approach, you can build
> in the security at the protocol so that you don’t rely fully on the
> binding for authentication and encryption.
>
> Discussions in some WGs have been debating XML or JSON and there are 2
> camps here, but the theory of having a data model approach and selecting
> one for the WG seems to be the go-forward decision.
>
> Best regards,
>
> Kathleen
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf
> Of [email-masked]
> *Sent:* Monday, May 14, 2012 3:24 PM
> *To:* [email-masked]; [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: [sacm] Request for participants - Content Repository
> *From: *<Waltermire>, David Waltermire <[email-masked]
> <mailto:[email-masked]>>
> *To: *"[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>, SCAP-DEV
> <[email-masked] <mailto:[email-masked]>>, "[email-masked]
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> *Subject: *Re: [sacm] Request for participants - Content Repository
>     One problem with SOAP web services is that they are often considered
>     very heavy weight. From what I have seen, the IETF tends to prefer
>     lighter weight protocols (e.g. REST, standardized messages over
>     HTTP, etc). Anyone else have any insights on this?
>
>     Sincerely,
>
>     Dave
>
>     From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked]] On Behalf Of Chandrashekhar B
>
>     To: SCAP-DEV; [email-masked] <mailto:[email-masked]>
>
>     repository. I had proposed a simple WSDL in a presentation I shared
>     with Kent, last year's ITSAC. We are looking forward to take active
>     participation in it.
>
>     Thanks,
>
>     Chandra.
>
>     www.secpod.com
>
>     From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked]] On Behalf Of Gunnar Engelbach
>
>     Cc: SCAP-DEV; [email-masked] <mailto:[email-masked]>
>
>     It would be great to have as many of these considerations as
>     possible in mind from the start as the actual work begins. As
>     another example, I'd like to see active participation from vendors
>     that have commercial content repositories so those concerns also
>     don't have to be later addressed with major changes.
>
>     But we also see a lot of these type of topics come up on the lists,
>     get discussed for a bit, then languish. If reducing the problem set
>     is what it takes to spur some action, let's get started.
>
>     It kinda sounds like this is headed towards having a dedicated
>     working group to take it on, which is what I'd prefer to see, so I'm
>     avoiding making specific comments until then.
>
>         *From:[email-masked]
>         <mailto:[email-masked]>
>         [mailto:[email-masked]]
>
>         *To:* [email-masked] <mailto:[email-masked]>;
>         Waltermire, David A.; SCAP-DEV;
>
>     [email-masked] <mailto:[email-masked]>
>
>         just
>         architecture.
>         point, it has been done.
>         <mailto:[email-masked]>
>
>         <mailto:[email-masked]>
>
>         <mailto:[email-masked]>
>         <mailto:[email-masked]%3e>>, SCAP-DEV
>         <[email-masked] <mailto:[email-masked]>
>
>         <mailto:[email-masked]> <mailto:[email-masked]%3e>>,
>         "[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>         <mailto:[email-masked]%3e>"
>
>         <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>         <mailto:[email-masked]%3e>>
>
>         [email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked]>
>
>         *From:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked]>
>
>         <mailto:[email-masked]>
>
>         *From:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked]>
>
>         <mailto:[email-masked]>
>
>         <mailto:[email-masked]> <mailto:[email-masked]%3e>>
>
>         <mailto:[email-masked]%3e>>
>
>         <mailto:[email-masked]%3e>"
>
>         <mailto:[email-masked]%3e>>
>
>         <mailto:[email-masked]>
>
>         <mailto:[email-masked]> <mailto:[email-masked]%3e>]
>
>         <mailto:[email-masked]>
>
>         [email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked]> with
>
>         <mailto:[email-masked]>
>
>         [email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked]> with
>
>         <mailto:[email-masked]>
>
>         [email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked]> with
>
>         <mailto:[email-masked]>
>
>         [email-masked] <mailto:[email-masked]>
>
>     [email-masked] <mailto:[email-masked]>
>
>     [email-masked] <mailto:[email-masked]>
>
>     [email-masked] <mailto:[email-masked]>
>

---

From: "Halbardier, Adam [USA]" <[email-masked]>
Date: Tue, 29 May 2012 15:34:49 +0000

Forgive the delayed response. While REST is lightweight compared to SOAP, SOAP is favorable when the slew of WS-* specifications are leveraged (read: required). The capabilities many WS-* specifications bring to SOAP as built-in features have to be brute-forced in a manual fashion in REST. In that case, SOAP holds a certain elegance that's lost on REST. When those requirements aren't present, though, REST does generally reduce the complexity and message size of services.

-Adam

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sean Turner
Sent: Wednesday, May 23, 2012 5:39 AM
To: [email-masked]
Cc: SCAP-DEV; [email-masked]; [email-masked]
Subject: Re: [scap-dev] [sacm] Request for participants - Content Repository Specification Development

Kent,

Technically, authors can specify really just about anything they want - but they're going to have to defend it.  Some defenses are easier than others.  At least one person said they'd have to ask why SOAP, and that they'd be skeptical of any answer that didn't involve interoperating with something written a long time ago.

I asked around some to verify that my impression wasn't just mine and confirmed that SOAP has pretty much fallen out of favor while REST seems to be where it's at.  You might ask why - well SOAP is XML based and XML has also fallen out of favor.  As Kathleen pointed out, all the cool kids are doing JSON ;)  For some, REST doesn't rely on XML so it's just better.

Hope this helps,

spt

PS - But, if JSON ends up being used you're going to have to wait for a security solution.

On 5/14/12 3:39 PM, [email-masked] wrote:
> protocol design was a better fit.  REST wasn’t popular then, so we 
> also took the approach to separate out the protocol from the binding 
> to allow for changes later (add new bindings).  With this approach, 
> you can build in the security at the protocol so that you don’t rely 
> fully on the binding for authentication and encryption.
>
> camps here, but the theory of having a data model approach and 
> selecting one for the WG seems to be the go-forward decision.
>
> Best regards,
>
> Kathleen
>
>         <mailto:[email-masked]%3e>>
>
> content
> piece
> approach
> last
> size
> detracting
> Developer
> last
> certain
> security
> becoming
> content
_______________________________________________
scap-dev mailing list
[email-masked]
To unsubscribe, send an email message to [email-masked].

---

From: "Halbardier, Adam [USA]" <[email-masked]>
Date: Tue, 29 May 2012 15:55:14 +0000

I agree with this. There's lots of ways to communicate information, with varying trade-offs, but we're already pretty entrenched in XML in the security automation space, so unless there's going to be massive shift to JSON, we're probably not going to benefit from having a one-off spec that uses it.

As for specifying the transport protocol: while it's alluring to leave the transport mechanism open, and allow anyone to implement anything, with any authentication mechanism, because different organizations have different needs, that won't foster interoperability of tools. We need to specify the function of a repository, the vision for federation, and concrete requirements on how those repositories are to communicate. At least then we have a fighting chance of interoperability in the future.

Best,
-Adam

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of WOLFKIEL, JOSEPH L CIV DISA PEO-MA
Sent: Friday, May 18, 2012 6:42 AM
To: Panos Kampanakis; Waltermire, David A.; SCAP-DEV; [email-masked]
Subject: Re: [scap-dev] [sacm] Request for participants - Content RepositorySpecification Development

If we're trying for interoperability, it seems like we'll need to specify the transport and security.  I'd hate to end up with something where every consumer must be able to consume any combination of JSON, XML, CSV over REST or SOAP because we didn't pick a standard configuration.

I like using REST if possible because the DoD in the Web Services STIG has made SOAP-based web services difficult and expensive.  I like XML because we already have to do XML parsing for OVAL and XCCDF, so I don't really see the allure of having to parse JSON for the service then having to parse XML for the content.

Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(301) 225-8820
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Panos Kampanakis
Sent: Thursday, May 17, 2012 6:30 PM
To: 'Waltermire, David A.'; SCAP-DEV; [email-masked]
Subject: Re: [scap-dev] [sacm] Request for participants - Content RepositorySpecification Development

2 thoughts: 

Rgs,

Panos

Here is the draft:

Sincerely,

Dave

Kent,

Sincerely,

Dave

Mike wrote: 

We need to talk more.

So here is what I am thinking.  We should consider addressing these as two separate but integrated efforts.  I believe the Organizational Content Repository is the more critical piece that is actually easier to address.  The Federated Content Distribution should be a subsequent effort integrating / augmenting the Organizational repository specification. 

Mike, to your point that we need someone to build one first. That has happened already.  I have one as do other vendors but what we don't have is the access specification.  Ours are focused on our specific product needs.  Additionally there is a company that has developed a commercial SCAP content repository that will be announced later this month. I won't steal their thunder but I was recently given a sneak peek at it and I must admit I was very impressed.  Again, to your point, it has been done. What is needed to address the initial operational problem is to develop a specification that provides a consistent means for all SCAP products to retrieve the appropriate content as configured and managed but the site.  

TO THAT END..

Thanks!

Kent Landfield

Direct: +1.972.963.7096 
Mobile: +1.817.637.8026

From: <Kinney>, Michael A <[email-masked]>
To: David Waltermire <[email-masked]>, SCAP-DEV <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA

	Dave,

	Thanks for the links.

	We need to talk more.

	-Mike  

	Mike,

	Here are the links:

	Sincerely,

	Dave

	Kent,

	v/r

	Mike Kinney

	Project Director

	 

	From:[email-masked] [mailto:[email-masked]] On Behalf Of Waltermire, David A.
	Sent: Monday, May 07, 2012 7:09 PM
	To: Multiple recipients of list
	Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA

	Kent,

	Thoughts?

	Sincerely,

	David Waltermire

	SCAP Architect

	(301) 975-3390

	From:[email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
	Sent: Monday, May 07, 2012 4:25 PM
	To: SCAP-DEV
	Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA

	All,

	For example:

	Operationally we have a real need to be able to deliver SCAP content internally within an organization. Today the SCAP vendors cannot share a single local site security policy (XCCDF + OVAL + CPE +.) without the site staff having to go to each of the individual products and figuring out how to inject that new or updated policy into that products delivery mechanisms.  That is limiting sites from wanting to buy multiple focused SCAP products since they are such a pain to manage from a content perspective.  It is easier to buy from one vendor that has a single means for distributing content than it is to deal with the management issues that having multiple SCAP products presents.  We need to have at least an entire 1/2 a day on the development of a Content Repository specification.

	I am really disappointed that Remediation is not on the list below.  Yes, last Summer Dev Days, the time spent on Remediation was wasted time but that does not mean we should ignore it and not try to make some real progress.  As far as I am concerned we need to reboot the remediation effort.  We cannot keep being the set of specifications / tools that act as the little boy crying "Wolf" in the night.  We need to be able to find and fix issues if we are going to really make a difference in organizational security postures.  But today we think it is too hard so we don't try ?  I think we need a couple hours to discuss the reboot of the effort even if that means minimizing work already done.

	A focused discussion on enterprise reporting is also critically needed.  For the vendors here, we have all gone through the Cyberscope goat rope, delivering limited capabilities to specific data call requirements of the Federal Agencies.  The initial effort was a mess, did little more than prove it was possible and cause the vendor community a great deal of thrashing to put a kludgey 'solution' in place.  Reality is all our customers need roll up reporting and an infrastructure that supports it.  A data call should not be special to anyone other than the agencies responding. The tools should be able to select the types of data needed and deliver that on a scheduled basis automatically.    Enterprise Reporting pertains to commercial as well as Federal customers.  We need to focus some time on what that would look like using the ARF and ASR as the foundational pieces.  But there are missing pieces..  We need this discussed.

	Thanks.

	Kent Landfield

	Direct: +1.972.963.7096 
	Mobile: +1.817.637.8026

	From: <Boczenowski>, Steve <[email-masked]>
	Reply-To: "OVAL Developer List (Closed Public Discussion)" <[email-masked]>
	To: "[email-masked]" <[email-masked]>
	Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA

		Frank;

		CCE

		CPE/SWID

		CEE

		XCCDF

		OVAL

		ASR

		Enterprise OCIL

		CybOX/MAEC

		MILE

		TAXII

		IF-M for SCAP

		IF-MAP

		SCAP Releases

		SCAP and IETF

		NETCONF and SCAP

		Steve

		Steve....

		Thanks,
		Frank Acker

		Details to follow.

		Regards,

		    Steve

		Stephen P. Boczenowski

		      The MITRE Corporation

		      Office: (781) 271-7682

		      Cell: (978) 302-3849

		     [email-masked]

		To unsubscribe, send an email message to [email-masked] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [email-masked]. 

		To unsubscribe, send an email message to [email-masked] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [email-masked]. 

		To unsubscribe, send an email message to [email-masked] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [email-masked].