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

["Halbardier, Adam [USA]" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Sean Turner
Sent: Wednesday, May 23, 2012 5:39 AM
To: [e-mail]
Cc: SCAP-DEV; [e-mail]; [e-mail]
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, [e-mail] 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:*[e-mail] [mailto:[e-mail]] *On Behalf 
> Of *[e-mail]
> *Sent:* Monday, May 14, 2012 3:24 PM
> *To:* [e-mail]; [e-mail]
> *Cc:* [e-mail]
> *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*
> 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: *<Waltermire>, David Waltermire <[e-mail] 
> <mailto:[e-mail]>>
> *To: *"[e-mail] <mailto:[e-mail]>"
> <[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] Request for participants - Content Repository 
> Specification Development
>
>     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: [e-mail] <mailto:[e-mail]>
>     [mailto:[e-mail]] On Behalf Of Chandrashekhar B
>
>     Sent: Saturday, May 12, 2012 2:43 AM
>
>     To: SCAP-DEV; [e-mail] <mailto:[e-mail]>
>
>     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: [e-mail] <mailto:[e-mail]>
>     [mailto:[e-mail]] On Behalf Of Gunnar Engelbach
>
>     Sent: Friday, May 11, 2012 11:33 PM
>
>     Cc: SCAP-DEV; [e-mail] <mailto:[e-mail]>
>
>     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:
>
>         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]>
>         [mailto:[e-mail]]
>
>         *Sent:* Friday, May 11, 2012 12:36 PM
>
>         *To:* [e-mail] <mailto:[e-mail]>;
>         Waltermire, David A.; SCAP-DEV;
>
>     [e-mail] <mailto:[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]
>         <mailto:[e-mail]>
>
>         <mailto:[e-mail]>
>         <mailto:[e-mail]%3e>>
>
>         *To: *David Waltermire <[e-mail]
>         <mailto:[e-mail]>
>
>         <mailto:[e-mail]>
>         <mailto:[e-mail]%3e>>, SCAP-DEV
>         <[e-mail] <mailto:[e-mail]>
>
>         <mailto:[e-mail]> <mailto:[e-mail]%3e>>,
>         "[e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
>         <mailto:[e-mail]%3e>"
>
>         <[e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
>         <mailto:[e-mail]%3e>>
>
>         *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]>
>
>     <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]>
>         <mailto:[e-mail]>
>
>         *From:*[e-mail] <mailto:*[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]>
>         <mailto:[e-mail]>
>
>         *From:*[e-mail] <mailto:*[e-mail]>
>         <mailto:[e-mail]>
>
>         [mailto:[e-mail]] <mailto:[mailto:[e-mail]]> 
> *On
>
>         Behalf Of *[e-mail]
>         <mailto:*[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]>
>
>         <mailto:[e-mail]> <mailto:[e-mail]%3e>>
>
>         *Reply-To: *"OVAL Developer List (Closed Public Discussion)"
>
>         <[e-mail]
>         <mailto:[e-mail]>
>
>         <mailto:[e-mail]>
>         <mailto:[e-mail]%3e>>
>
>         *To: *"[e-mail]
>         <mailto:[e-mail]>
>
>         <mailto:[e-mail]>
>         <mailto:[e-mail]%3e>"
>
>         <[e-mail]
>         <mailto:[e-mail]>
>
>         <mailto:[e-mail]>
>         <mailto:[e-mail]%3e>>
>
>         *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]>
>
>         <mailto:[e-mail]> <mailto:[e-mail]%3e>]
>
>         *Sent:* Tuesday, March 20, 2012 16:38
>
>         *To:* [e-mail]
>         <mailto:[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]>
>         <mailto:[e-mail]>
>
>         To unsubscribe, send an email message to
>
>         [e-mail] <mailto:[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]>
>
>         <mailto:[e-mail]>.
>
>         To unsubscribe, send an email message to
>
>         [e-mail] <mailto:[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]>
>
>         <mailto:[e-mail]>.
>
>         To unsubscribe, send an email message to
>
>         [e-mail] <mailto:[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]>
>
>         <mailto:[e-mail]>.
>
>         _______________________________________________
>
>         sacm mailing list
>
>         [e-mail] <mailto:[e-mail]>
>
>         https://www.ietf.org/mailman/listinfo/sacm
>
>     _______________________________________________
>
>     sacm mailing list
>
>     [e-mail] <mailto:[e-mail]>
>
>     https://www.ietf.org/mailman/listinfo/sacm
>
>     _______________________________________________
>
>     sacm mailing list
>
>     [e-mail] <mailto:[e-mail]>
>
>     https://www.ietf.org/mailman/listinfo/sacm
>
>     _______________________________________________
>
>     sacm mailing list
>
>     [e-mail] <mailto:[e-mail]>
>
>     https://www.ietf.org/mailman/listinfo/sacm
>
_______________________________________________
scap-dev mailing list
[e-mail]
To unsubscribe, send an email message to [e-mail].