Re: [sacm] [scap-dev] Request for participants - Content RepositorySpecification Development

["Waltermire, David A." <[e-mail]>]

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
National Institute of Standards and Technology
[phone]
[e-mail]


> -----Original Message-----
> From: WOLFKIEL, JOSEPH L CIV DISA PEO-MA
> [mailto:[e-mail]]
> Sent: Friday, May 18, 2012 9:42 AM
> To: Panos Kampanakis; Waltermire, David A.; SCAP-DEV; [e-mail]
> 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
> [phone]
> [e-mail]
>
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Panos Kampanakis
> Sent: Thursday, May 17, 2012 6:30 PM
> To: 'Waltermire, David A.'; SCAP-DEV; [e-mail]
> Subject: Re: [scap-dev] [sacm] Request for participants - Content
> RepositorySpecification Development
>
> 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
>
>
>
>
>
>
>
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Waltermire, David A.
> Sent: Wednesday, May 16, 2012 3:39 PM
> To: SCAP-DEV; [e-mail]
> Subject: Re: [sacm] Request for participants - Content Repository
> Specification Development
>
>
>
> 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: '[e-mail]'; [e-mail]; SCAP-DEV;
> [e-mail]
> 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: [e-mail] [mailto:[e-mail]]
> Sent: Friday, May 11, 2012 12:36 PM
> To: [e-mail]; Waltermire, David A.; SCAP-DEV;
> [e-mail]
> Subject: Request for participants - Content Repository Specification
> Development
>
>
>
> 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
> Director Content Strategy, Architecture and Standards
>
> McAfee | An Intel Company
> 5000 Headquarters Dr.
> Plano, Texas 75024
>
> Direct: +1.972.963.7096
> Mobile: [phone]
> Web: www.mcafee.com <http://www.mcafee.com/>
>
>
>
> From: <Kinney>, Michael A <[e-mail]>
> To: David Waltermire <[e-mail]>, SCAP-DEV <SCAP-
> [e-mail]>, "[e-mail]" <[e-mail]>
> 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:[e-mail]]
>       Sent: Tuesday, May 08, 2012 10:44 AM
>       To: Kinney, Michael A; SCAP-DEV; [e-mail]
>       Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer
> Days: Summer 2012 at MITRE in Bedford, MA
>
>
>
>       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:[e-mail]]
>       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.
>
>
>
>       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: [phone]
>       NSTS: 968-8886
>       Fax [phone]
>
>       [e-mail] <mailto:[e-mail]>
>
>
>
>
>
>
>
>       From:[e-mail] [mailto:[e-mail]] 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
>
>       [phone]
>
>       [e-mail]
>
>
>
>       From:[e-mail] [mailto:[e-mail]] On Behalf Of
> [e-mail]
>       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
>       Director Content Strategy, Architecture and Standards
>
>       McAfee | An Intel Company
>       5000 Headquarters Dr.
>       Plano, Texas 75024
>
>       Direct: +1.972.963.7096
>       Mobile: [phone]
>       Web: www.mcafee.com <http://www.mcafee.com/>
>
>
>
>       From: <Boczenowski>, Steve <[e-mail]>
>       Reply-To: "OVAL Developer List (Closed Public Discussion)" <OVAL-
> [e-mail]>
>       To: "[e-mail]" <OVAL-DEVELOPER-
> [e-mail]>
>       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:[e-mail]]
>               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 [[e-mail]]
>               Sent: Tuesday, March 20, 2012 16:38
>               To: [e-mail]
>               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: [phone]
>
>                     Cell: [phone]
>
>                    [e-mail]
>
>
>
>               To unsubscribe, send an email message to
> [e-mail] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY
> of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-
> [e-mail].
>
>               To unsubscribe, send an email message to
> [e-mail] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY
> of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-
> [e-mail].
>
>               To unsubscribe, send an email message to
> [e-mail] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY
> of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-
> [e-mail].