Re: [sacm] Request for participants - Content Repository Specification Development

[Gunnar Engelbach <[e-mail]>]

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, [e-mail] wrote:
> 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]
> <mailto:[e-mail]>>
> To: David Waltermire <[e-mail]
> <mailto:[e-mail]>>, SCAP-DEV <[e-mail]
> <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>"
> <[e-mail] <mailto:[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] <mailto:[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]>
>     [mailto:[e-mail]] <mailto:[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] <mailto:[e-mail]>
>
>     *From:*[e-mail] <mailto:[e-mail]>
>     [mailto:[e-mail]] <mailto:[mailto:[e-mail]]> *On
>     Behalf Of *[e-mail] <mailto:[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]
>     <mailto:[e-mail]>>
>     *Reply-To: *"OVAL Developer List (Closed Public Discussion)"
>     <[e-mail]
>     <mailto:[e-mail]>>
>     *To: *"[e-mail]
>     <mailto:[e-mail]>"
>     <[e-mail]
>     <mailto:[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]
>         <mailto:[e-mail]>]
>         *Sent:* Tuesday, March 20, 2012 16:38
>         *To:* [e-mail]
>         <mailto:[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 MITRECorporation
>
>         Office: [phone]
>
>         Cell: [phone]
>
>         [e-mail] <mailto:[e-mail]>
>
>         To unsubscribe, send an email message to
>         [e-mail] <mailto:[e-mail]> with
>         SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you
>         have difficulties, write to
>         [e-mail]
>         <mailto:[e-mail]>.
>
>         To unsubscribe, send an email message to
>         [e-mail] <mailto:[e-mail]> with
>         SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you
>         have difficulties, write to
>         [e-mail]
>         <mailto:[e-mail]>.
>
>         To unsubscribe, send an email message to
>         [e-mail] <mailto:[e-mail]> with
>         SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you
>         have difficulties, write to
>         [e-mail]
>         <mailto:[e-mail]>.
>
>
>
> _______________________________________________
> sacm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sacm