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

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:
> 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
> (301) 975-3390
> david.waltermire@nist.gov
>
>
>> -----Original Message-----
>> From: WOLFKIEL, JOSEPH L CIV DISA PEO-MA
>> [mailto:joseph.wolfkiel@disa.mil]
>> Sent: Friday, May 18, 2012 9:42 AM
>> To: Panos Kampanakis; Waltermire, David A.; SCAP-DEV; sacm@ietf.org
>> 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
>> Joseph.Wolfkiel@DISA.mil
>>
>>
>> -----Original Message-----
>> From: scap-dev-bounces@nist.gov [mailto:scap-dev-bounces@nist.gov] On
>> Behalf Of Panos Kampanakis
>> Sent: Thursday, May 17, 2012 6:30 PM
>> To: 'Waltermire, David A.'; SCAP-DEV; sacm@ietf.org
>> 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: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of
>> Waltermire, David A.
>> Sent: Wednesday, May 16, 2012 3:39 PM
>> To: SCAP-DEV; sacm@ietf.org
>> 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: 'Kent_Landfield@McAfee.com'; m.kinne@radium.ncsc.mil; SCAP-DEV;
>> sacm@ietf.org
>> 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: Kent_Landfield@McAfee.com [mailto:Kent_Landfield@McAfee.com]
>> Sent: Friday, May 11, 2012 12:36 PM
>> To: m.kinne@radium.ncsc.mil; Waltermire, David A.; SCAP-DEV;
>> sacm@ietf.org
>> 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: +1.817.637.8026
>> Web: www.mcafee.com<http://www.mcafee.com/>
>>
>>
>>
>> From:<Kinney>, Michael A<m.kinne@radium.ncsc.mil>
>> To: David Waltermire<david.waltermire@nist.gov>, SCAP-DEV<SCAP-
>> DEV@nist.gov>, "sacm@ietf.org"<sacm@ietf.org>
>> 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:david.waltermire@nist.gov]
>>        Sent: Tuesday, May 08, 2012 10:44 AM
>>        To: Kinney, Michael A; SCAP-DEV; sacm@ietf.org
>>        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:m.kinne@radium.ncsc.mil]
>>        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: 410-854-4422
>>        NSTS: 968-8886
>>        Fax 410-854-4681
>>
>>        makinn2@nsa.gov<mailto:M.kinne@radium.ncsc.mil>
>>
>>
>>
>>
>>
>>
>>
>>        From:scap-dev@nist.gov [mailto:scap-dev@nist.gov] 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
>>
>>        david.waltermire@nist.gov
>>
>>
>>
>>        From:scap-dev@nist.gov [mailto:scap-dev@nist.gov] On Behalf Of
>> Kent_Landfield@mcafee.com
>>        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: +1.817.637.8026
>>        Web: www.mcafee.com<http://www.mcafee.com/>
>>
>>
>>
>>        From:<Boczenowski>, Steve<sboczeno@MITRE.ORG>
>>        Reply-To: "OVAL Developer List (Closed Public Discussion)"<OVAL-
>> DEVELOPER-LIST@LISTS.MITRE.ORG>
>>        To: "OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG"<OVAL-DEVELOPER-
>> LIST@LISTS.MITRE.ORG>
>>        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:afrank@NOVA.EDU]
>>                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 [sboczeno@MITRE.ORG]
>>                Sent: Tuesday, March 20, 2012 16:38
>>                To: OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG
>>                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
>>
>>                     sboczeno@mitre.org
>>
>>
>>
>>                To unsubscribe, send an email message to
>> LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY
>> of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-
>> request@LISTS.MITRE.ORG.
>>
>>                To unsubscribe, send an email message to
>> LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY
>> of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-
>> request@LISTS.MITRE.ORG.
>>
>>                To unsubscribe, send an email message to
>> LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY
>> of the message. If you have difficulties, write to OVAL-DEVELOPER-LIST-
>> request@LISTS.MITRE.ORG.
>
> _______________________________________________
> sacm mailing list
> sacm@ietf.org
> https://www.ietf.org/mailman/listinfo/sacm