&nb= sp;

I think that the hub idea may be needed at the beginnin= g. The rationale is probably that standardization cannot be achieved = without one. However, after some level of performance is achieved the= effort can be decentralized. The management can be perhaps rotated t= o reduce/share the burden. The rotated management approach may give t= he participants a better feel for what works in the best interest of s= tandardization and all particpating parties.

David Oliva

On 05/21/12, Waltermire, David A.<davi= d.waltermire@nist.gov> wrote:

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

Any other thou= ghts?

Sincerely,
Dave

-----Original Message-----
Fr= om: Michael Hammer [mailto:michael.hammer@yaanatech.com]
Sen= t: Monday, May 21, 2012 1:18 PM
To: Waltermire, David A.; G= unnar.Engelbach@ThreatGuard.com
Cc: SCAP-DEV; sacm@ietf.org
Subject= : RE: [sacm] [scap-dev] Request for participants - Content Repository Speci= fication Development

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

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

Mike

-----Original Message-----
From:= Waltermire, David A. [mailto:david.waltermire@nist.gov]
Sent: = Monday, May 21, 2012 1:09 PM
To: Michael Hammer; Gunnar.Eng= elbach@ThreatGuard.com
Cc: SCAP-DEV; sacm@ietf.org
Subject: RE: [sa= cm] [scap-dev] Request for participants - Content Repository
Specificati= on Development

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

Sincerely,
Dave

-= ----Original Message-----
From: Michael Hammer [mailto:michael.h= ammer@yaanatech.com]
Sent: Monday, May 21, 2012 12:59 PM
To: Walt= ermire, David A.; Gunnar.Engelbach@ThreatGuard.com
Cc: = SCAP-DEV; sacm@ietf.org
Subject: RE: [sacm] [scap-dev] Request for partici= pants - Content Repository
Specification Development

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

Po= lling seems like it could get chatty, and raises the question of how
oft= en.

Mike

-----Original Message-----
From: sacm-bounc= es@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of
Walterm= ire, David A.
Sent: Monday, May 21, 2012 10:42 AM
To: Gunnar Engelbac= h
Cc: SCAP-DEV; sacm@ietf.org
Subject: Re: [sacm] [scap-dev] Request fo= r participants - Content Repository
Specification Development

Com= ments inline marked [DAW].

Sincerely,
Dave

-----Origin= al Message-----
From: sacm-bounces@ietf.org [mailto:sacm-bounces@= ietf.org] On Behalf Of
Gunnar Engelbach
Sent: Friday, May 18, 201= 2 1:04 PM
Cc: SCAP-DEV; sacm@ietf.org
Subject: Re: [sacm] [scap-dev] Re= quest for participants - Content Repository
Specification Development

Dave,

It sounds like you are trying to solve two separate p= roblems here.

The first is the ability to retrieve content from a re= pository, the second
is the ability to locate repositories.

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

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

For example, a configuration scanning age= nt is ordered by the scanning
manager to perform a scan on a repeating i= nterval using a set of content.
The set of content required is a list of= OVAL definition IDs developed by a
third party vendor hosted in the thi= rd party vendor's content repository.
The agent has been preconfigured t= o point to the local content repository to
which it sends a request to f= or the content. The local repository looks up
the namespace associated w= ith the third party content IDs in DNS retrieving
the SRV record for the= third party content repository. It dispatches a
request for the content= to the third party repository and retrieves the
content, caching it, an= d providing it to the client.]

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

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

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

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

[DAW: My= example pre-supposes that the content IDs have already been
selected. M= eaning that the organization performing the scan pre-selected
content fr= om the third party registry. This introduces a third problem that
needs = to be solved that is a discovery style problem. For the web, we have
web= -based search engines that index content from a variety of sources and
t= hen provide persistent pointers to the location of the content. We
proba= bly need something like this too, but that is a concept that more than
l= ikely needs to be addressed by one or more additional specifications.
Initially, organizations are going to seek content from sources that act = as
authorities for their organization or that are trusted. Discovery mat= ters
at the point where digital policy is constructed. In this scenario,= if a
content repository supports simple standardized query capabilities= , we
probably have a workable solution for the short-term. In my example= above,
the scanning manager is responsible for many different agents on= many
different hosts. The system user would create scanning configurati= ons based
on content they have pre-selected and these configurations wou= ld then get
propagated to the individual scanners. The pre-selection cou= ld be the
result of querying a list of authoritative and trusted reposit= ories. This
usage pattern also applies to single host and agentless appr= oaches.]

--gun

On 5/18/2012 8:42 AM, Waltermire, Davi= d A. wrote:
> My comments marked with [DAW2].
>
> Sincere= ly,
> Dave
>
>
> -----Original Message-----
>= From: Chandrashekhar B [mailto:bchandra@secpod.com]
> Sent: Frida= y, May 18, 2012 1:50 AM
> To: Waltermire, David A.; 'Kurt Seifried'> Cc: sacm@ietf.org; SCAP-DEV
> Subject: RE: [sacm] [scap-dev] Req= uest for participants - Content
> Repository Specification Developmen= t
>
> My comments marked [CHA]
>
> Chandra.
>=
> -----Original Message-----
> From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf
> Of
Waltermire, = David A.
> Sent: Friday, May 18, 2012 8:02 AM
> To: Kurt Seifri= ed
> Cc: sacm@ietf.org
> Subject: Re: [sacm] [scap-dev] Request = for participants - Content
> Repository Specification Development
= >
> Comments inline marked [DAW].
>
> Sincerely,
&g= t; Dave
>
>
> -----Original Message-----
> From: Ku= rt Seifried [mailto:kseifried@redhat.com]
> Sent: Thursday, May 1= 7, 2012 10:18 PM
> To: Waltermire, David A.
> Cc: sacm@ietf.org> Subject: Re: [scap-dev] [sacm] Request for participants - Content> Repository Specification Development
>
> -----BEGIN PGP S= IGNED MESSAGE-----
> Hash: SHA1
>
> Note: all opinions/co= mments are my own, not official Red Hat policy
> and so
on.
>= ;
> On 05/17/2012 07:19 PM, Waltermire, David A. wrote:
>> K= urt,
>>
>> My assumption is that each organization would = stand up a content
>> repository based on this specification for t= heir own authoritative
>> content, content they produce. They woul= d sign the content using
>> their own private key. I haven't worke= d out an approach for public
>> key distribution yet. It would be = if we could use DNS or some other
>> standardized key distribution= mechanism. I am open to ideas.
>
> Ah my bad I assumed you guy= s were talking about the central repo
> (although
at some point th= ere has to be a head repo, right?). As far as keys go why
recreate the w= heel? Use X.509 and sign stuff, then key distribution is
trivial (use th= e system keys, allow import of a custom key, etc.). Plus this
way you're= using well tested system libraries/etc. which are available by
default = (well on any sane OS).
>
> [DAW: I am assuming that there will = be no central repo. From talking
> with
content publishers, there = are IP rights and other issues with this type of
approach. I think the b= etter solution is to support a distributed network
of repositories. Some= organizations and consortiums may decide to stand up
centralized repos = for their own purposes. This should be allowed, but not
required.
>= ;
> [CHA: Yes, distributed network of repository, with may be a centr= al
> registry. Even for a central registry, I feel we aren't there ye= t.
> Central repository or a registry would mean getting into operati= onal
> aspects, who'll own, manage, control etc., So, limiting it to<= BR>> organizational repositories and content providers repository is goo= d
> in my view.]
>
> [DAW2: This is why I am advocating f= or a federated system. With the
> right approach, we can avoid having= to stand up a single central
> registry and all the operational and = logistical aspects involved.
> Using the DNS SRV approach below, DNS = essentially becomes the
> registry. Using DNS, every organization tha= t produces content is able
> to point to the authoritative content re= positories that they use to
> host their content. They can create as = many namespaces as needed, by
> using sub-domains within their own do= main(s). A SRV record would be
> associated with each sub-domain in t= his case.]
>
> As far as supporting repo resolution, I am recom= mending a namespaced
content identifier approach based on DNS names. Man= y of the security
automation identifiers have reverse DNS names incorpor= ated into them. For
those that done, simple DNS namespace qualification = would provide the same
effect. In either case, this info can be used to = lookup the content
repository that is authoritative for the content refe= renced by the ID. This
can be handled using a DNS SRV record (RFC2783). = We would need to get an
IANA allocation for this (RFC6335). This approac= h avoids having to create a
root server infrastructure for content repos= itories.
>
> I'd like to hear other thoughts related to X.509.]=
>
> [CHA: I am not sure if I understand the DNS resolution app= roach here
> completely, will anyway pose a question. If one content = repository
> were to host a content authored by someone else and the = namespace
> wasn't modified, may be for IP reasons. DNS namespace qua= lification
> would not work if I want to pick the content from this r= epository
> instead of the original author. Not sure if I am making s= ense :) ]
>
> [DAW2: I am modeling this approach after DNS. The= re are authoritative
content servers that originate content. The DNS SRV= records would be mapped
to the DNS namespaces hosted by a given authori= tative content server. This
is an analog to domains hosted by an authori= tative DNS server. Here is a
basic communication flow:
>
> 1= ) Client: sends request for content by ID to local, organizational
conte= nt repository.
> 2) Organizational repository: retrieve the requested= content
> a) If the namespace is a local namespace, return the conte= nt.
> b) If the namespace is a foreign namespace, check if the conten= t is
> in
the local cache.
> c) Lookup the DNS SRV record as= sociated with the ID's namespace.
> d) Dispatch a request to the fore= ign authoritative content
> repository
based on the SRV record to = retrieve the content
> e) Cache the retrieved content using the time-= to-live (TTL) value
provided by the remote server.
> 3) Organizati= onal repository: respond to the client with the content
>
> Thi= s approach allows content for a given namespace to be managed by a
singl= e authoritative content repository. If a third party is hosting
content = for another (e.g. repository-as-a-service), then the DNS SRV record
for = the content's ID namespace would point to the 3rd party hosted
repositor= y.
>
> Access to local cache can (and probably should) be limit= ed to IPs
> within an organization or thru the use of access controls= to prevent
> leakage of cached content.]
>
>> It may = also make sense to allow for counter signing of content to
>> allo= w 3rd parties to sign content. Again, I have not worked out how
>>= best to do this. Any ideas?
>
> Chained signatures would be re= ally nice, e.g. Linux vendor releases an
> RPM
with signed files, = customer can then certify them and sign them, so if you
allowed people t= o simply sign data (so "sign1(data)") and in turn that to be
signed (e.g= . "sign2(sign1(data))") you could support any reasonably sane use
case (= e.g. we require the sysadmin to use a departmentally signed thing
which = in turn requires an org cert which requires a gov cert which requires
to= vendor signature, etc.). I don't think the case of having multiple
sign= atures "At the same level" is significant, and can be fudged using
signa= ture chains.
>
> [DAW: agreed.]
>
>> Related to = restricting access to content, it is my hope that content
>> is ma= de freely available. For some kinds of content, it probably
>> mak= es sense to support some kind of access control. This could be
>> = driven by commercialization of content or to restrict access to some
>= ;> content to authorized users within an organization.
>> Clien= t/Server certificates might be a mechanism to support this.
>
>= I would classify content rights management as well beyond the scope of
= this project (you know have to basically build a CA type entity, handle cer= t
revocation for expired clients, etc, etc, etc.) and something to be le= ft up
to the end vendor/customer that actually wants this. Building in D= RM is a
huge amount of effort and I suspect it would mostly be wasted. A= ny content
management you build in will:
>
> 1) be incompati= ble (and thus either removed, or an active problem) for
> many vendor= s/customers (I doubt any existing system for selling
> content will e= nd up being super compatible with what you guys build)
> 2) be unnece= ssary in most (if not almost all) cases
> 3) add significantly to the= overhead of building this and not add any
> real value to the actual= problem space of securing machines
>
> For some idea of the sc= ope of this type of problem check out
> http://www.candlepinproj= ect.org/ which provides subscription and
> entitlement management= . Even without reinventing the wheel, but just
integrating with somethin= g like candlepin would be a huge effort. I would
say this problem is lef= t to any vendors that want to put DRM on the
content/etc.
>
>= ; TLDR: Please, please don't do this, it'll be a huge time/effort sink
&= gt; and
not worth it. Anyone that wants to sell this kind of thing alrea= dy has
systems capable of delivering files and managing access/rights to= them.
>
> [DAW: Points well taken. I am interested in other th= oughts on how
> best to address this. What I was recommending was loo= king more
> towards service authentication and less towards DRM. Mayb= e we don't
> address this in the first pass. Thoughts?]
>
&g= t; [CHA: Access control is definitely a requirement for organizational
c= ontent server as well as content providers repository. Once the service is<= BR>authenticated, it should be left to the implementers to define/implement=
their own access rights. Because, an entity communicating with the
r= epository will not see any difference in the behavior.
>
> In o= ur repository, we have implemented a policy driven access control
> a= nd
the policy parameters are the attributes of SCAP metadata. But, someo= ne else
might choose an hierarchical database and define container level= access
control.
>
> So, service authentication is required = to be standardized. For access
> control, may be an error condition i= f one is not allowed to fetch the
> content?]
>
> [DAW2: = agreed. I see this as a minimal standardization approach.]
>
>&= gt; I hope this answers your questions.
>>
>> Sincerely, = Dave
>>
>>
>> -----Original Message----- From: K= urt Seifried
>> [mailto:kseifried@redhat.com] Sent: Thursday, = May 17, 2012 9:11 PM
>> To: Waltermire, David A. Subject: Re: [sca= p-dev] [sacm] Request for
>> participants - Content Repository Spe= cification Development
>>
>> On 05/17/2012 04:44 PM, Walt= ermire, David A. wrote:
>>> Good points. It makes sense to use = the mechanisms provided by XML
>>> (e.g. XMLDsig, XML Encryptio= n) and capabilities provided by the
>>> underlying transport (e= .g. TLS) to address as much of this as
>>> possible. It may be = desirable to provide mechanisms for
>>> authentication to restr= ict access to content. This may also need to
>>> be integrated = into the underlying transport.
>> I have some questions, asking of= f list, not sure if they are
>> appropriate, if they are feel free= to reply on the list.
>>
>> 1) if using XMLDsig who woul= d be the signing authority? How secure
>> would signing be (e.g. u= sing a hardware card/appliance/etc?).
>> Where would the key be pu= blished/would it be signed/etc? 2) You
>> mention restricting acce= ss to content, why would the content need to
>> be restricted? Are= there IP issues I am unaware of?
>>
>> Thanks
>>= ;
>>> Sincerely, Dave
>>
> - - --
> Kurt S= eifried Red Hat Security Response Team (SRT)
> PGP: 0x5E267993 A90B F= 995 7350 148F 66BF 7554 160D 4553 5E26 7993
> -----BEGIN PGP SIGNATUR= E-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using Gn= uPG with Mozilla - http://enigmail.mozdev.org/
>
> iQIcBAEB= AgAGBQJPtbFIAAoJEBYNRVNeJnmTuwsQANiygjm9i8AAjiwXMWb3K/RZ
> uIcqM+kbO1= 8cFIWce7p5njzcmRx2eeFFpmMfMTWPrfs7AMjSRjpGy9DNQ9wvlIyR
> GVgwpeWiIK3c= ZJza3YFEhUfpng3Ivek3kp3nKDgTgm7wBATi0NrRMG6/QRPxxJnK
> MXPjON4aenqInI= FxRGoDqplR7e6g6RXuaD4B376f+LC0R7j8lWUK4ug/GTkBPkXf
> LfDuY1Q4u9ctB+tX= WQyCwRe4sQ2Gd+PXYzyDENa9kd3e5P/6LTWn3spZQvfEa0Ew
> xQj8YB5VbsyT39Gvtl= JOV0cJ35HOZBGhwtqwa3vJ6xE3sWCNuJdWqvHr7T8A0Qus
> u4VO6Gc6S6Nrq6DbU9tn= 11jMoDwwP1wtqFx+l9bhhzSw5VNKVnkTq7/Q0fXd9Q2r
> GfPp0ZplyL4lRfhfglt/dK= bGPOoiOhuFXKeJw9MVQRU0ZHRKxnpw+DeFoBCQXpUH
> TdHBg7gu37yB/dAxs63CZKlC= 1GDi8nXNZ4+myTDDsnqogzbkP61p3acoYFuunLGK
> +JMj0f3OktzZRFqylUbrqw/ONH= O5zvZOjZp6pQAikG9Vvn89PsmuXHZvbNJRlaqi
> oiTDzeONz3yyvwjEYg5J1i11e+tz= M6x248ulclh+82CwhKL9G1AotFIi803iXrbv
> XCldnHSPS6O7qeRTgMtL
> = =3DQJsL
> -----END PGP SIGNATURE-----
> _______________________= ________________________
> sacm mailing list
> sacm@ietf.org
&= gt; https://www.ietf.org/mailman/listinfo/sacm
>> _______________________________________________
> sacm mailing= list
> sacm@ietf.org
> https://www.ietf.org/mai= lman/listinfo/sacm
_______________________________________________sacm mailing list
sacm@ietf.org
https://www.ietf.org/m= ailman/listinfo/sacm
_______________________________________________=
sacm mailing list
sacm@ietf.org
https://www.ietf.org= /mailman/listinfo/sacm
_____________________________________________= __
sacm mailing list
sacm@ietf.org
https://www.ietf.o= rg/mailman/listinfo/sacm

From bchandra@secpod.com Thu Jun 14 13:10:16 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C0521F877A for ; Thu, 14 Jun 2012 13:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.242 X-Spam-Level: * X-Spam-Status: No, score=1.242 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpN5SdIgBnFh for ; Thu, 14 Jun 2012 13:10:05 -0700 (PDT) Received: from cpanel23.interactivedns.com (cpanel23.interactivedns.com [184.173.122.2]) by ietfa.amsl.com (Postfix) with ESMTP id A9F4321F873A for ; Thu, 14 Jun 2012 13:10:04 -0700 (PDT) Received: from [122.172.14.165] (port=27490 helo=hpPC) by cpanel23.interactivedns.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1SfGMi-0002Ps-Mk; Fri, 15 Jun 2012 01:40:03 +0530 From: "Chandrashekhar B" To: "'Multiple recipients of list'" , References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov> In-Reply-To: Date: Fri, 15 Jun 2012 01:39:54 +0530 Organization: SecPod Technologies Message-ID: <00a801cd4a69$aba5be40$02f13ac0$@secpod.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A9_01CD4A97.C567E550" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJt5r4nvn6Xg4466qYgTE+iSkxyIpW5BFnQ Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel23.interactivedns.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - secpod.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [sacm] Request for participants - Content Repository Specification Development X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bchandra@secpod.com List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol $SCAP$." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 20:10:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00A9_01CD4A97.C567E550 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable We have hosted our SCAP Content Repository at www.scaprepo.com. Feedback = is certainly appreciated. A simple web service interface will be published soon. =20 Chandra. =20 From: scap-dev@nist.gov [mailto:scap-dev@nist.gov] On Behalf Of Kent_Landfield@mcafee.com Sent: Friday, May 11, 2012 10:14 PM To: Multiple recipients of list Subject: Request for participants - Content Repository Specification Development =20 Mike I love it when you tee something up like that.. ;-) Thank you. ;) =20 Mike wrote:=20 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. =20 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. ;) =20 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.=20 =20 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. ;) =20 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.=20 =20 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. =20 =20 TO THAT END.. =20 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.=20 =20 Thanks! =20 Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096=20 Mobile: +1.817.637.8026 Web: www.mcafee.com =20 =20 From: , Michael A To: David Waltermire , SCAP-DEV , "sacm@ietforg " = Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA =20 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. =20 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. =20 -Mike =20 =20 From: Waltermire, David A. [mailto:david.waltermire@nist.gov]=20 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 =20 Mike, =20 What about having webinars in-place of the 30 minute briefs? =20 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. =20 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. =20 Remediation is a topic near and dear to my heart. I too would like to = see it move forward. =20 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). =20 Here are the links: =20 http://csrc.nist.gov/publications/PubsDrafts.html http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7848 =20 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. =20 I am also looking forward to the discussions at the conference. It has = been too long. =20 Sincerely, Dave =20 From: Kinney, Michael A [mailto:m.kinne@radium.ncsc.mil ]=20 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 =20 Kent, =20 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=AE2 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. =20 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. =20 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. =20 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. =20 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. =20 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. =20 I look forward to talking with you at the conference. =20 v/r =20 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 =20 =20 =20 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 =20 Kent, =20 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. =20 Thoughts? =20 Sincerely, =20 David Waltermire SCAP Architect National Institute of Standards and Technology (301) 975-3390 david.waltermire@nist.gov =20 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 =20 All, =20 I would like to discuss the format for the SCAP Developer Days that = seems to be listed below. =20 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. =20 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. =20 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: =20 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. =20 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. =20 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. =20 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. =20 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. =20 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. =20 Thanks. =20 Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096=20 Mobile: +1.817.637.8026 Web: www.mcafee.com =20 =20 From: , Steve Reply-To: "OVAL Developer List (Closed Public Discussion)" To: "OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG" Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA =20 Frank; =20 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. =20 Meanwhile, we are working on the agenda and are currently considering = this list of topics: =20 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 =20 Steve =20 From: Frank Lindsay Acker [mailto:afrank@NOVA.EDU]=20 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 =20 Steve.... Has there been any additional information regarding this event? Thanks, Frank Acker _____ =20 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 =20 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. =20 Details to follow. =20 Regards, Steve =20 ______________________________________________ Stephen P. Boczenowski The MITRE Corporation Office: (781) 271-7682 Cell: (978) 302-3849 sboczeno@mitre.org =20 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.=20 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.=20 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.=20 ------=_NextPart_000_00A9_01CD4A97.C567E550 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

We have hosted our SCAP Content Repository at www.scaprepo.com. Feedback is = certainly appreciated. A simple web service interface will be published = soon.

Chandra.

From:= = scap-dev@nist.gov [mailto:scap-dev@nist.gov] On Behalf Of = Kent_Landfield@mcafee.com
Sent: Friday, May 11, 2012 10:14 = PM
To: Multiple recipients of list
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

From: = <Kinney>, Michael A <m.kinne@radium.ncsc.mil>To: David Waltermire <david.waltermire@nist.gov&g= t;, SCAP-DEV <SCAP-DEV@nist.gov>, "sacm@ietforg" <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.go= v]
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.ni= st.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=AE2 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

= 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.comSent: 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.

Presentations are sent out to the attendees and = the lists a week in advance
Status for any effort is limited to 30 = minutes
Focused brainstorming time should be established = for certain areas that need real work by the = community
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.

From: = <Boczenowski>, Steve <sboczeno@MITRE.ORG>
Reply= -To: "OVAL Developer List (Closed Public Discussion)" = <OVAL-DEVELOPER-LIST@L= ISTS.MITRE.ORG>
To: "OVAL-DEVELOPER-LIST@L= ISTS.MITRE.ORG" <OVAL-DEVELOPER-LIST@L= ISTS.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@L= ISTS.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-DEVELOPE= R-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-DEVELOPE= R-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-DEVELOPE= R-LIST-request@LISTS.MITRE.ORG.

------=_NextPart_000_00A9_01CD4A97.C567E550-- From david.oliva@verizon.net Thu Jun 14 16:38:53 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED87E21F8512 for ; Thu, 14 Jun 2012 16:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.796 X-Spam-Level: ** X-Spam-Status: No, score=2.796 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGOEaErN0XbD for ; Thu, 14 Jun 2012 16:38:51 -0700 (PDT) Received: from vms173019pub.verizon.net (vms173019pub.verizon.net [206.46.173.19]) by ietfa.amsl.com (Postfix) with ESMTP id C39CB21F8510 for ; Thu, 14 Jun 2012 16:38:50 -0700 (PDT) Received: from vznit170130pub.verizon.net ([unknown] [192.168.1.3]) by vms173019.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0M5M00MLKSCA44E0@vms173019.mailsrvcs.net> for sacm@ietf.org; Thu, 14 Jun 2012 18:38:35 -0500 (CDT) Received: from 216.231.4.2 ([216.231.4.2]) by vznit170130 (Verizon Webmail) with HTTP; Thu, 14 Jun 2012 18:38:34 -0500 (CDT) Date: Thu, 14 Jun 2012 18:38:34 -0500 (CDT) From: david.oliva@verizon.net To: bchandra@secpod.com, scap-dev@nist.gov, sacm@ietf.org Message-id: <14684411.1695189.1339717114359.JavaMail.root@vznit170130> MIME-version: 1.0 Content-type: text/html; charset=UTF-8 Content-transfer-encoding: quoted-printable X-Mailer: Verizon Webmail X-Originating-IP: [216.231.4.2] Subject: Re: [sacm] Request for participants - Content Repository Specification Development X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol $SCAP$." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 23:38:53 -0000
To = all:

Perhaps NIST should write a guidance Specia= l Publication based on SP 800-70 but as a set of requirements that reposito= ries should have. For instance, that repositories display the tier le= vel (Tier I, II, III, and IV) and the specifications used in the content.

David Oliva (Ruben)

<= div>
On 06/= 14/12, Chandrashekhar B<bchandra@secpod.com> wrote:

We have hosted our SCAP Content Repository at www.scaprepo.com. Feedback is certa= inly appreciated. A simple web service interface will be published soon.
<= /p>
Chandra.
=

=
From: scap-dev@nist.gov [mailto:scap-dev@nist.gov] On Behalf Of <= /b>Kent_Landfield@mcafee.com
Sent: Friday, May 11= , 2012 10:14 PM
To: Multiple recipients of list
Subject= : Request for participants - Content Repository Specification Developme= nt

Mike I love it when you te= e something up like that=E2=80=A6. ;-) Thank you. ;)
=

Mike wrote:&n= bsp;
I still think that any specification for a repo= sitory is wishful thinking until someone builds one and learns the lessons = it will just be another whitepaper spec. I believe the DoD needs to i= ncorporate a metadata repository as part of it and other customizations tha= t may not be useful for everyone.=
We need to talk mo= re=E2=80=A6;

<= span style=3D"color:black">If you are talking about a holistic, complete fe= derated approach to a content repository, I some what agree. If you a= re talking about an organizational repository, I totally disagree. But you = knew I would. ;)

Here is how I see the problem. There i= s an immediate need for SCAP and other related content to be served up insi= de an organization. Today we have situation where the standards allow= us to provide sites the capability to have a single SCAP implemented polic= y they call official for their environment. Yes this is a rather simplistic= since there are things such as targeting specific platforms, specific oper= ational use needs, but for now lets agree SCAP is a massive improvement ove= r the proprietary situations of the past. While we have created this standa= rd content so that sites can implement their local site security once and t= hen assure they are measuring all appropriately targeted devices the same w= ay, we have failed to support the operational needs of the sites. We = have a situation where no two vendors distribute content the same way. &nbs= p;This causes massive problems for the administration staff when they need = to incorporate a new SCAP enabled product into their architecture. Th= ey need to discover how the new product supports distributing SCAP content = to it's various components. If they have one product then they do thi= s one and they are done. If they have multiple products they will hav= e to figure out how to minimize the impact by incorporating the update proc= ess 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 t= o their security policy, they have to make the modifications to the benchma= rk 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 conten= t repository problem and that is the Federated Content Distribution. = If you think global DNS you have a general frame of reference. The gu= idance authors need to be able to publish content in an authoritative manne= r so their content is updated in a timely fashion. This is a much har= der problem to solve if there is no local organizational infrastructure to = support it. ;)

So her= e is what I am thinking=E2=80=A6 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 ad= dress. The Federated Content Distribution should be a subsequent effo= rt integrating / augmenting the Organizational repository specification.&nb= sp;

Mike, to your poi= nt that we need someone to build one first=E2=80=A6 That has happened alrea= dy. I have one as do other vendors but what we don=E2=80=99t have is = the access specification. Ours are focused on our specific product ne= eds. Additionally there is a company that has developed a commercial = SCAP content repository that will be announced later this month. I won't st= eal their thunder but I was recently given a sneak peek at it and I must ad= mit I was very impressed. Again, to your point, it has been done. Wha= t is needed to address the initial operational problem is to develop a spec= ification that provides a consistent means for all SCAP products to retriev= e the appropriate content as configured and managed but the site.

TO THAT END=E2=80=A6.

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

Thank= s!

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

From: <K= inney>, Michael A <m.kinne@radium.ncsc.mil>
To= : David Waltermire <david.waltermire@nist.gov>, SCA= P-DEV <SCAP-DEV@nist.gov>, "sacm@ietforg" <sacm@i= etf.org>
Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Secur= ity Automation Developer Days: Summer 2012 at MITRE in Bedford, MA

Dave,
I have no problem with web= inars, I do want to keep developer days actionable and use it to make decis= ions, and vote and accomplish things good or bad. I do not want this = to be an informational briefing conference.
Thanks f= or the links.

I still = think that any specification for a repository is wishful thinking until som= eone builds one and learns the lessons it will just be another whitepaper s= pec. 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=E2=80=A6;
=
= -Mike

From: Wa= ltermire, David A. [mailto:david.waltermire@nist.gov]
<= b>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,<= /p>

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

Regarding content managem= ent, we are building the prototype content repository for use in a producti= on environment. As an open source project, it will be free for use by= anyone interested. My thinking is that this project can bridge the g= ap until commercial solutions are available to augment it. This is a = similar path that was followed with DNS (bind) and HTTP (apache). Whe= n it is ready for use, I am hoping to use it to host USGCB content. Y= ou 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 continuo= us monitoring. I would also like to see some discussion on OCIL at De= veloper 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 meet= ing.

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

We just published= the draft ASR specification for public comment. This specification s= upports enterprise aggregate reporting which greatly reduces the data volum= es needed verses detailed host-based reports. This specification has been d= esigned as a more robust replacement for LASR It can be used in conti= nuous 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/publicati= ons/PubsNISTIRs.html#NIST-IR-7848
<= span style=3D"color:black">
The primary reason we have suggested waiting on XCCDF is no= t 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 occu= rred. As we consider changes to the SCAP stack to address OCIL and ot= her issues, we will identify areas that need improvement in XCCDF. Th= ese 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 l= ooking forward to the discussions at the conference. It has been too = long.
<= span style=3D"color:#1F497D">
Sincerely,<= /span>
Dave

<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif";color:black">From: Kinney, Mic= hael A [mailto:m.kinne@radium.ncsc.mil]
Sent: Tuesd= ay, May 08, 2012 7:09 AM
To: SCAP-DEV
Cc: Waltermir= e, David A.
Subject: RE: [OVAL-DEVELOPER-LIST] Security Automat= ion Developer Days: Summer 2012 at MITRE in Bedford, MA

Kent,

It= =E2=80=99s good to read your thoughts, and a realistic actionable approach = is indeed needed Since all the activity hasn=E2=80=99t been on the li= sts a brief 1=C5=BD2 hour recap may be in order to bring everyone up to spe= ed 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 st= and one up it will be as valuable as the CCSS specification is today. = ;I=E2=80=99ve been trying for two years to get my management to get a coord= inated effort together for the DoD to stand up a repository, it is a tough = problem and will require funding with a tail, I=E2=80=99m not sure a specif= ication will solve that problem.<= /p>

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

Remediation i= s stalled but I=E2=80=99m making every effort to get it kick started from o= ur perspective. I hope to assist in getting the draft ERI finished this yea= r. 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 au= tomatic configuration fixes, part of a self healing network concept. It is = just a start but the best we can do at this point.
&= nbsp;
<= span style=3D"color:#1F497D">Enterprise reporting is an interesting subject= , since XML adds size to and content to roll up reporting, in any enterpris= e of size the problem gets greater, I look forward to your thoughts on that= subject.
<= /span>
I am concern= ed that the internationalization efforts are detracting from efforts to mee= t 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=E2=80=99= t think that a move to internationalization should impede efforts to move f= orward 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: 9= 68-8886
Fax 410-854-4681
=
makinn2@nsa.gov
<= span style=3D"color:black">

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: Mu= ltiple recipients of list
Subject: RE: [OVAL-DEVELOPER-LIST] Se= curity Automation Developer Days: Summer 2012 at MITRE in Bedford, MA
=
Kent,
<= p class=3D"MsoNormal">
I like what you are saying here. We are also in support of thi= s type of approach. We would like to see some community discussion ar= ound 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.&= nbsp; For each area we should focus the discussion around developing object= ives for each session. The sessions can be time boxed based on what w= ould 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 =E2=80=9Con deck=E2=80=9D if all the objec= tives are reached and we complete all the scheduled sessions early.<= span style=3D"color:black">

Thoughts?

Sincerely,

D= avid Waltermire
SCAP Architect
National Institute of Standards and Technology
(30= 1) 975-3390
david.waltermire@nist.gov
<= span style=3D"color:black">
= From:scap-d= ev@nist.gov [mailto:scap-dev@nist.gov] On Behalf Of <= /b>Kent_Landfield@mcafee.com
Sent: Monday, May 07= , 2012 4:25 PM
To: SCAP-DEV
Subject: Re: [OVAL-DEVE= LOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bed= ford, MA

=
All,

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

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 awa= y from 'Death by Powerpoint' and back to the type of event we held years ag= o when we were highly productive. In the past we had a topic to be di= scussed and a time box to work within. That allowed us to have very a= ctive brainstorming sessions in a high bandwidth environment.

At past Summ= er 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 dis= cussions. We need to keep moving forward and making progress as an ef= fort. We can get status from various places such as the lists, a presentati= on being sent out in advance, a webinar if it is felt there will be questio= ns and answers from those that are new to the efforts. We have a limi= ted 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 d= eal of time reeducating everyone when we could be focused on advancing need= ed 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 ot= her efforts.
Presentations are sent out to the attendees and = the lists a week in advance
Status for any effort is limited to 30 minutes
Focused brainstorming time should be established f= or certain areas that need real work by the community
Efforts to be discussed should be based on nee= ds of the security automation space to move existing efforts to completion.=
For examp= le:

Continuous monitoring is a major direction the efforts are becoming in= volved with. There are going to be things we need to do as a security autom= ation community to be able to accomplish what is listed in the CAESARS FE. = There are interfaces that need to be worked and established. Th= at 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 addr= ess 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 abl= e to deliver SCAP content internally within an organization. Today the SCAP= vendors cannot share a single local site security policy (XCCDF + OVAL + C= PE +=E2=80=A6) without the site staff having to go to each of the individua= l products and figuring out how to inject that new or updated policy into t= hat 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 ma= nagement 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 Reposi= tory specification.

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

<= div>
I am really disappoi= nted that Remediation is not on the list below=E2=80=A6 Yes, last Sum= mer Dev Days, the time spent on Remediation was wasted time but that does n= ot mean we should ignore it and not try to make some real progress. A= s 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 organizationa= l security postures. But today we think it is too hard so we don't tr= y ? I think we need a couple hours to discuss the reboot of the effor= t 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 cap= abilities 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 reporti= ng and an infrastructure that supports it. A data call should not be = special to anyone other than the agencies responding. The tools should be a= ble to select the types of data needed and deliver that on a scheduled basi= s automatically. Enterprise Reporting pertains to commercial a= s 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=E2=80=A6. We need this discussed.

I would = hope we can make this summer's SCAP Dev Days useful in advancing the securi= ty automation efforts by addressing some of the more critical issues our cu= stomers are facing now or will be facing in the very short term. Stat= us 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 pro= gress while we are all in the same room. This is always a big event f= or 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 C= ontent Strategy, Architecture and Standards

McAfee | An= Intel Company
5000 H= eadquarters Dr.
Plano, Texas 7= 5024

Direct: +1.972.963.= 7096
Mobile: +1.817.637.= 8026
Web: www.mcafee.com<= /span>

F= rom: <Boczenowski>, Steve <= sboczeno@MITRE.ORG>
Reply-To: "OVAL Developer Li= st (Closed Public Discussion)" <OVAL-DEVELOPER-= LIST@LISTS.MITRE.ORG>
To: "OVAL= -DEVELOPER-LIST@LISTS.MITRE.ORG" <OVAL-DEVE= LOPER-LIST@LISTS.MITRE.ORG>
Subject: Re: [OVAL-DEVELOPER= -LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford,= MA

Frank;
<= span style=3D"color:black">
We hope to have the registration site up next week. T= he event will be during the week of July 9 =E2=80=93 starting Monday at 10:= 00 AM and ending on Friday at 12:00.

Meanwhile, we are working on the agenda and are currently co= nsidering this list of topics:

CCE<= /span>
CPE/SWID
C= EE
XCCDF
OVAL
ASR
Enterpr= ise OCIL
CybOX/MAEC
Federated Content Repository S= pec
Endpoint Reporting fo= r Continuous Monitoring and Compliance (ERCC)
MILE
TAXII
IF-M for SCAP
IF-MAP
SCAP Releases
SCAP and IETF<= /p>
NETCONF and SCAP

Steve

<= b>From: Frank Li= ndsay Acker [mailto:afrank@NOVA.EDU]
Sent: Tuesday, May 01= , 2012 9:32 AM
To: oval-developer-list OVAL Developer List/Clos= ed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] Securit= y Automation Developer Days: Summer 2012 at MITRE in Bedford, MA

Stev= e....

Has there been any additional information regarding this e= vent?

Thanks,
Frank Acker
From: Boczenowski, Steve [sboczeno= @MITRE.ORG]
Sent: Tuesday, March 20, 2012 16:38
To:= OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG
Su= bject: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer= 2012 at MITRE in Bedford, MA
=
Save the Date: week of July 9, 2012
= ;
This year=E2=80=99s MITRE-hosted Security Automation Devel= oper Days event will be held during the week of July 9, 2012 at MITRE=E2=80= =99s facility in Bedford, MA.

Details to f= ollow.

Regards,
  &= nbsp; Steve

_____________________________________________= _
Stephen P. Bocze= nowski
     = 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 ha= ve difficulties, write to OVAL-DEVELOPER-LIST-r= equest@LISTS.MITRE.ORG.
<= /div>
To unsubscribe, send an email message to LISTS= ERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the= message. If you have difficulties, write to O= VAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG.
To un= subscribe, send an email message to LISTSERV@LISTS.MITRE.ORG w= ith SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have dif= ficulties, write to OVAL-DEVELOPER-LIST-request= @LISTS.MITRE.ORG.
<= /div>

_______________________________________________
sacm mailing listsacm@ietf.org
https://www.ietf.org/mailman/li= stinfo/sacm
From david.waltermire@nist.gov Fri Jun 15 12:23:21 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B7711E80E2 for ; Fri, 15 Jun 2012 12:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.358 X-Spam-Level: X-Spam-Status: No, score=-5.358 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvyjpg0m4Hph for ; Fri, 15 Jun 2012 12:23:07 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 48DDB11E80CD for ; Fri, 15 Jun 2012 12:23:05 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 15 Jun 2012 15:22:56 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Fri, 15 Jun 2012 15:20:33 -0400 From: "Waltermire, David A." To: "bchandra@secpod.com" , SCAP-DEV , "sacm@ietf.org" Date: Fri, 15 Jun 2012 15:23:03 -0400 Thread-Topic: [sacm] Request for participants - Content Repository Specification Development Thread-Index: AQJt5r4nvn6Xg4466qYgTE+iSkxyIpW5BFnQgAGGgJA= Message-ID: References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov> <00a801cd4a69$aba5be40$02f13ac0$@secpod.com> In-Reply-To: <00a801cd4a69$aba5be40$02f13ac0$@secpod.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D7A0423E5E193F40BE6E94126930C4930B9BA83FFDMBCLUSTERxcha_" MIME-Version: 1.0 Subject: Re: [sacm] Request for participants - Content Repository Specification Development X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol $SCAP$." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 19:23:22 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930B9BA83FFDMBCLUSTERxcha_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable I am not sure how to use the search page properly. Would you please provid= e some example searches? Sincerely, Dave From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Cha= ndrashekhar B Sent: Thursday, June 14, 2012 4:10 PM To: SCAP-DEV; sacm@ietf.org Subject: Re: [sacm] Request for participants - Content Repository Specifica= tion Development We have hosted our SCAP Content Repository at www.scaprepo.com. Feedback is certainly appreciated. A simple web service inter= face will be published soon. Chandra. From: scap-dev@nist.gov [mailto:scap-dev@nist.gov= ] On Behalf Of Kent_Landfield@mcafee.com= Sent: Friday, May 11, 2012 10:14 PM To: Multiple recipients of list Subject: Request for participants - Content Repository Specification Develo= pment 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 u= ntil someone builds one and learns the lessons it will just be another whit= epaper 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 conte= nt repository, I some what agree. If you are talking about an organization= al repository, I totally disagree. But you knew I would. ;) Here is how I see the problem. There is an immediate need for SCAP and oth= er related content to be served up inside an organization. Today we have s= ituation where the standards allow us to provide sites the capability to ha= ve a single SCAP implemented policy they call official for their environmen= t. 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 th= eir local site security once and then assure they are measuring all appropr= iately targeted devices the same way, we have failed to support the operati= onal needs of the sites. We have a situation where no two vendors distribu= te content the same way. This causes massive problems for the administrati= on staff when they need to incorporate a new SCAP enabled product into thei= r architecture. They need to discover how the new product supports distrib= uting SCAP content to it's various components. If they have one product th= en 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 up= date process for the new product into the existing SCAP security content pr= ocesses. 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 th= e benchmark or checks or both and then distribute those updates across thei= r network. For each SCAP enabled product they have in place, they have dou= bled, tripled or more the work needed to make those updates available. There is another content repository problem and that is the Federated Conte= nt Distribution. If you think global DNS you have a general frame of refer= ence. The guidance authors need to be able to publish content in an author= itative manner so their content is updated in a timely fashion. This is a = much harder problem to solve if there is no local organizational infrastruc= ture to support it. ;) So here is what I am thinking... We should consider addressing these as tw= o separate but integrated efforts. I believe the Organizational Content Re= pository is the more critical piece that is actually easier to address. Th= e 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 hap= pened already. I have one as do other vendors but what we don't have is th= e access specification. Ours are focused on our specific product needs. A= dditionally there is a company that has developed a commercial SCAP content= repository that will be announced later this month. I won't steal their th= under but I was recently given a sneak peek at it and I must admit I was ve= ry impressed. Again, to your point, it has been done. What is needed to ad= dress the initial operational problem is to develop a specification that pr= ovides 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 tal= ked 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 From: , Michael A > To: David Waltermire >, SCAP-DEV >, "sacm@ietf= org" > Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation Developer Day= s: Summer 2012 at MITRE in Bedford, MA Dave, I have no problem with webinars, I do want to keep developer days actionabl= e 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 u= ntil someone builds one and learns the lessons it will just be another whit= epaper 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: Summ= er 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 reposit= ory for use in a production environment. As an open source project, it wil= l be free for use by anyone interested. My thinking is that this project c= an 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. Y= ou would be welcome to use it for your needs. It is good that OCIL is moving forward. This is an important piece of supp= orting 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 a= chieve 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 spe= cification supports enterprise aggregate reporting which greatly reduces th= e data volumes needed verses detailed host-based reports. This specificatio= n has been designed as a more robust replacement for LASR It can be used i= n continuous monitoring applications to support aggregate data reporting ne= eds (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 internatio= nalization issue. Many vendors have commented that they are still working o= n 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 con= sider changes to the SCAP stack to address OCIL and other issues, we will i= dentify 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 a= re 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 sh= ould be ready to work on a new revision of XCCDF. I am also looking forward to the discussions at the conference. It has bee= n 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: Summ= er 2012 at MITRE in Bedford, MA Kent, It's good to read your thoughts, and a realistic actionable approach is ind= eed needed Since all the activity hasn't been on the lists a brief 1=AE2 h= our recap may be in order to bring everyone up to speed since there has bee= n a lot of activity on CPE/SWID, OCIl, MAEC/CybOX CEE and others. We could write a content repository specification, but without someone will= ing to stand one up it will be as valuable as the CCSS specification is tod= ay. I've been trying for two years to get my management to get a coordinat= ed effort together for the DoD to stand up a repository, it is a tough prob= lem 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 try= ing 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 f= rom our perspective. I hope to assist in getting the draft ERI finished thi= s 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 au= tomatic 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 gr= eater, I look forward to your thoughts on that subject. I am concerned that the internationalization efforts are detracting from ef= forts 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 d= idn't think that a move to internationalization should impede efforts to mo= ve 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 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: Summ= er 2012 at MITRE in Bedford, MA Kent, I like what you are saying here. We are also in support of this type of ap= proach. 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 shou= ld focus the discussion around developing objectives for each session. The= sessions can be time boxed based on what would be a reasonable amount of t= ime to accomplish each objective. For example if continuous monitoring is = a priority and collectively it takes 3 days to work through all the objecti= ves, 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 sessio= ns 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<= mailto:Kent_Landfield@mcafee.com> Sent: Monday, May 07, 2012 4:25 PM To: SCAP-DEV Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA All, I would like to discuss the format for the SCAP Developer Days that seems t= o be listed below. I see this appears to follow a path we have discussed in the past as the wa= y not to hold a Dev Days event. We have been trying to get away from 'Deat= h by Powerpoint' and back to the type of event we held years ago when we we= re highly productive. In the past we had a topic to be discussed and a tim= e box to work within. That allowed us to have very active brainstorming se= ssions in a high bandwidth environment. At past Summer events we have got into a pattern of lots of powerpoint, lot= s of status of the efforts and very little discussion about things that nee= d active discussions. We need to keep moving forward and making progress a= s an effort. We can get status from various places such as the lists, a pre= sentation 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 li= mited amount of time and all who are attending are investing a great deal o= f time and money to be there. We should not be spending a great deal of t= ime reeducating everyone when we could be focused on advancing needed effor= ts. The type of approach to a Dev Days event was discussed at the last Summer D= ev 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 ad= vance 2. Status for any effort is limited to 30 minutes 3. Focused brainstorming time should be established for certain areas tha= t need real work by the community 4. Efforts to be discussed should be based on needs of the security autom= ation space to move existing efforts to completion. For example: Continuous monitoring is a major direction the efforts are becoming involve= d 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. Ther= e 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 w= hat has already been solved. We need to address the needed interface devel= opment 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 intern= ally within an organization. Today the SCAP vendors cannot share a single l= ocal site security policy (XCCDF + OVAL + CPE +...) without the site staff = having to go to each of the individual products and figuring out how to inj= ect that new or updated policy into that products delivery mechanisms. Tha= t is limiting sites from wanting to buy multiple focused SCAP products sinc= e 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 tha= n it is to deal with the management issues that having multiple SCAP produc= ts presents. We need to have at least an entire 1/2 a day on the developme= nt 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 secu= rity automation to do things on/for a single host. They need security auto= mation to focus on the enterprise issues that reduce their costs and improv= e their efficiencies. OCIL is failing in the enterprise and we all underst= and that. We need to address developing a definitive solution for incorpor= ating OCIL into the enterprise and that means into the existing specificati= ons. 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 option= s. 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 th= at 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 c= annot keep being the set of specifications / tools that act as the little b= oy crying "Wolf" in the night. We need to be able to find and fix issues i= f we are going to really make a difference in organizational security postu= res. 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 minim= izing work already done. A focused discussion on enterprise reporting is also critically needed. Fo= r the vendors here, we have all gone through the Cyberscope goat rope, deli= vering limited capabilities to specific data call requirements of the Feder= al 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 pu= t 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 b= e able to select the types of data needed and deliver that on a scheduled b= asis automatically. Enterprise Reporting pertains to commercial as well = as Federal customers. We need to focus some time on what that would look l= ike using the ARF and ASR as the foundational pieces. But there are missin= g pieces.... We need this discussed. I would hope we can make this summer's SCAP Dev Days useful in advancing th= e security automation efforts by addressing some of the more critical issue= s our customers are facing now or will be facing in the very short term. S= tatus presentations are not interesting to those active in the efforts. Le= t's try to do those before we get to Bedford so we can real make some progr= ess 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 automat= ion 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 mo= ves 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 From: , Steve > Reply-To: "OVAL Developer List (Closed Public Discussion)" > To: "OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG" > Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summ= er 2012 at MITRE in Bedford, MA Frank; We hope to have the registration site up next week. The event will be duri= ng 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: Summ= er 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 2= 012 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 h= eld 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@LI= STS.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@LI= STS.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@LI= STS.MITRE.ORG. --_000_D7A0423E5E193F40BE6E94126930C4930B9BA83FFDMBCLUSTERxcha_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
I am not sure how to use the search page properly.=A0 Would y= ou please provide some example searches?

Sincerely,=
Dave
<= /o:p>
From: sacm-bounces@ietf.= org [mailto:sacm-bounces@ietf.org] On Behalf Of Chandrashekhar B
= Sent: Thursday, June 14, 2012 4:10 PM
To: SCAP-DEV; sacm@i= etf.org
Subject: Re: [sacm] Request for participants - Content Re= pository Specification Development

We have hosted our SCAP Content Repository at www.scaprepo.com. Feedback is certainly appreciated. = A simple web service interface will be published soon.

Chandra.=

From: scap-dev@nist.gov [mailto:scap-dev@nist.gov] On Behalf Of Kent_Landfield@mcafee.com
Sent:= Friday, May 11, 2012 10:14 PM
To: Multiple recipients of listSubject: Request for participants - Content Repository Specificatio= n Development
&n= bsp;
Mike I love it when you tee something up like that…. ;-) Tha= nk you. ;)

Mike wrote:
I still think that any specification for a repository is wishful thi= nking until someone builds one and learns the lessons it will just be anoth= er whitepaper spec. I believe the DoD needs to incorporate a metadata= repository as part of it and other customizations that may not be useful f= or 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 yo= u are talking about an organizational repository, I totally disagree. But y= ou 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 ins= ide an organization. Today we have situation where the standards allo= w us to provide sites the capability to have a single SCAP implemented poli= cy they call official for their environment. Yes this is a rather simplisti= c since there are things such as targeting specific platforms, specific ope= rational use needs, but for now lets agree SCAP is a massive improvement ov= er the proprietary situations of the past. While we have created this stand= ard 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. &nb= sp;This causes massive problems for the administration staff when they need= to incorporate a new SCAP enabled product into their architecture. T= hey need to discover how the new product supports distributing SCAP content= to it's various components. If they have one product then they do th= is one and they are done. If they have multiple products they will ha= ve to figure out how to minimize the impact by incorporating the update pro= cess 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 benchm= ark or checks or both and then distribute those updates across their networ= k. For each SCAP enabled product they have in place, they have double= d, tripled or more the work needed to make those updates available.
&= nbsp;
Ther= e is another content repository problem and that is the Federated Content D= istribution. If you think global DNS you have a general frame of refe= rence. 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… W= e 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 Distr= ibution should be a subsequent effort integrating / augmenting the Organiza= tional repository specification.

Mike, to your point that we need someon= e 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 th= ere is a company that has developed a commercial SCAP content repository th= at will be announced later this month. I won't steal their thunder but I wa= s 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.

T= O 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 ha= ppen. I have talked to a couple of you but I do not want to assume yo= ur participation. If you are interested please contact me so we can g= et this started.

Thanks!

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfe= e | An Intel Company
5000= Headquarters Dr.
Plano, Texas 750= 24

Direct: +1.972.963.7096&nbs= p;
Mobile: +1.817.637.8026<= br>Web: www.mcafee.com

From: <Kinney>, Michael A <= m.kinne@radium.ncsc.mil>
To: David Waltermire <david.waltermire@nist.gov>, SC= AP-DEV <SCAP-DEV@nist.gov>, = "sacm@ietforg" <sacm@ietf.org>
Subject: Re: [sac= m] [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at= MITRE in Bedford, MA
=
Dave,
I have no problem with webi= nars, I do want to keep developer days actionable and use it to make decisi= ons, and vote and accomplish things good or bad. I do not want this t= o be an informational briefing conference.
= Thanks for the links.<= /p>

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

-Mike

= From: Waltermire, David A. [mailto:david.waltermire@nist.gov]
Sent: = Tuesday, May 08, 2012 10:44 AM
To: Kinney, Michael A; SCAP-DEV; <= a href=3D"mailto:sacm@ietf.org">sacm@ietf.org
Subject: RE: [O= VAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITR= E 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 an= yone interested. My thinking is that this project can bridge the gap = until commercial solutions are available to augment it. This is a sim= ilar path that was followed with DNS (bind) and HTTP (apache). When i= t 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 forwa= rd. This is an important piece of supporting risk management and aspe= cts of continuous monitoring. I would also like to see some discussio= n 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 o= utside the meeting.

Remediation is a topic near and dear to my heart. I t= oo would like to see it move forward.
= ;
We just published the draft ASR specifica= tion for public comment. This specification supports enterprise aggre= gate reporting which greatly reduces the data volumes needed verses detaile= d host-based reports. This specification has been designed as a more robust= replacement for LASR It can be used in continuous monitoring applica= tions to support aggregate data reporting needs (e.g. FISMA reporting, &nbs= p;CyberScope).

Here are the links:

http://csrc.nist.gov/publications/PubsDrafts.html<= span style=3D'color:black'>
http://csrc.nist.gov/publications/PubsNISTIRs.htm= l#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 occur= red. As we consider changes to the SCAP stack to address OCIL and oth= er issues, we will identify areas that need improvement in XCCDF. The= se 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.
Sub= ject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Sum= mer 2012 at MITRE in Bedford, MA
=
Kent,

It’s good to read your thoughts, and a realistic actionable ap= proach is indeed needed Since all the activity hasn’t been on t= he lists a brief 1=AE2 hour recap may be in order to bring everyone up to s= peed since there has been a lot of activity on CPE/SWID, OCIl, MAEC/CybOX C= EE and others.

We could write a content repository specification, but without s= omeone willing to stand one up it will be as valuable as the CCSS specifica= tion is today. I’ve been trying for two years to get my managem= ent to get a coordinated effort together for the DoD to stand up a reposito= ry, it is a tough problem and will require funding with a tail, I’m n= ot sure a specification will solve that problem.

We (DoD) have been putting a l= ot of effort into OCIL over the last year trying to make it useful in an en= terprise environment and will be posting our ideas to the list before devel= oper days it should have already started, we need to get consensus and a vo= te 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 s= ome new STIG content and intend to used the draft CRE specification to inse= rt CRE into the content so we (DoD) can do some automatic configuration fix= es, 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 si= ze the problem gets greater, I look forward to your thoughts on that subjec= t.

I= am concerned that the internationalization efforts are detracting from eff= orts 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 di= dn’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 confe= rence.

v/r

<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F49= 7D'>Mike Kinney
Project Director<= o:p>
Computer Network Defense Res= earch and Technology (CND R&T) Office
9800 Savage Road Ste 6767<= br>Ft Meade, MD 20755-6767
Phone: 410-854-4422
NSTS: 968-8886
Fax 410-854-4681
<= a href=3D"mailto:M.kinne@radium.ncsc.mil">mak= inn2@nsa.gov

From:scap= -dev@nist.gov [mailto:sca= p-dev@nist.gov] On Behalf Of Waltermire, David A.
Sent: Monday, May 07, 2012 7:09 PM
To: Multiple recipients of listSubject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Da= ys: Summer 2012 at MITRE in Bedford, MA<= o:p>

Kent,

I like what you are saying here. We are also in suppor= t of this type of approach. We would like to see some community discu= ssion around what are the key areas/priorities that the community would lik= e to see discussed at Dev Days. Your topics below look like a good st= art. The SACM list might be a better venue than the OVAL list for this disc= ussion. For each area we should focus the discussion around developin= g objectives for each session. The sessions can be time boxed based o= n what would be a reasonable amount of time to accomplish each objective.&n= bsp; 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 tha= t. We can also keep a few sessions “on deck” if all the o= bjectives are reached and we complete all the scheduled sessions early.
<= span style=3D'color:#1F497D'> =
Thought= s?

Sincerely,
=
David Waltermire
<= span style=3D'color:#1F497D'>SCAP Architect
National Institute of Standards and Technology
(301) 975-3390
david.waltermire@nist.gov

From:scap-dev@nist.go= v [mailto:scap-dev@nist.g= ov] On Behalf Of Ke= nt_Landfield@mcafee.com
Sent: Monday, May 07, 2012 4:25 PMTo: SCAP-DEV
Subject: Re: [OVAL-DEVELOPER-LIST] Security = Automation Developer Days: Summer 2012 at MITRE in Bedford, MA

All,<= /p>
<= /o:p>
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 pat= h we have discussed in the past as the way not to hold a Dev Days event. &n= bsp;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. I= n the past we had a topic to be discussed and a time box to work within. &n= bsp;That allowed us to have very active brainstorming sessions in a high ba= ndwidth environment.
<= span style=3D'color:black'>
At past Summer events we have got = into a pattern of lots of powerpoint, lots of status of the efforts and ver= y little discussion about things that need active discussions. We nee= d to keep moving forward and making progress as an effort. We can get statu= s from various places such as the lists, a presentation being sent out in a= dvance, a webinar if it is felt there will be questions and answers from th= ose 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 t= here. We should not be spending a great deal of time reeducatin= g everyone when we could be focused on advancing needed efforts.=
&nbs= p;
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.
Presentations are sent out to the attendees and= the lists a week in advance
Status for any effort is limited to 30 minutes
=
Focused brainstorming time shou= ld be established for certain areas that need real work by the community
Efforts to be disc= ussed should be based on needs of the security automation space to move exi= sting efforts to completion.
= For example:

=
Continuous moni= toring is a major direction the efforts are becoming involved with. There a= re going to be things we need to do as a security automation community to b= e able to accomplish what is listed in the CAESARS FE. There are inte= rfaces 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 so= lve what has already been solved. We need to address the needed inter= face 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 v= endors cannot share a single local site security policy (XCCDF + OVAL + CPE= +…) without the site staff having to go to each of the individual pr= oducts 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 fro= m 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 manage= ment issues that having multiple SCAP products presents. We need to h= ave 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 impleme= nted because of the limitations of how it addresses uses in an enterprise e= nvironment. People don't need security automation to do things on/for= a single host. They need security automation to focus on the enterpr= ise issues that reduce their costs and improve their efficiencies. OC= IL is failing in the enterprise and we all understand that. We need t= o 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.
&= nbsp;
I am really disappointed that Remediation is not on the list be= low… Yes, last Summer Dev Days, the time spent on Remediation w= as wasted time but that does not mean we should ignore it and not try to ma= ke 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. &nb= sp;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 d= iscuss the reboot of the effort even if that means minimizing work already = done.

A focused discussion on enterprise reporting is al= so 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 m= ess, did little more than prove it was possible and cause the vendor commun= ity a great deal of thrashing to put a kludgey 'solution' in place. R= eality is all our customers need roll up reporting and an infrastructure th= at supports it. A data call should not be special to anyone other tha= n the agencies responding. The tools should be able to select the types of = data needed and deliver that on a scheduled basis automatically. &nb= sp;Enterprise Reporting pertains to commercial as well as Federal customers= . We need to focus some time on what that would look like using the A= RF and ASR as the foundational pieces. But there are missing pieces&#= 8230;. We need this discussed.

I would hope we can= make this summer's SCAP Dev Days useful in advancing the security automati= on efforts by addressing some of the more critical issues our customers are= facing now or will be facing in the very short term. Status presenta= tions are not interesting to those active in the efforts. Let's try t= o 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 'con= sensus 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 al= l walk out the last day, we all feel that every minute was well spent and m= oves us forward.

Thanks.
<= /p>
Kent Landfield
Director Content Strategy, Ar= chitecture and Standards

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

D= irect: +1.972.963.7096
Mobil= e: +1.817.637.8026
Web: 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.O= RG>
Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation= Developer Days: Summer 2012 at MITRE in Bedford, MA
<= /div>

Frank;

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

Meanwhile, we are working on the agenda and are currentl= y considering this list of topics:<= /o:p>

CCE
CPE/SWID
CEE
XCCDF
OVAL
ASR
Ente= rprise OCIL
CybO= X/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<= o:p>
NETCONF and SCAP=
&n= bsp;
Steve
=
From:<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:blac= k'> Frank Lindsay Acker [mailto:afrank@N= OVA.EDU]
Sent: Tuesday, May 01, 2012 9:32 AM
To: o= val-developer-list OVAL Developer List/Closed Public Discussion
Subje= ct: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summe= r 2012 at MITRE in Bedford, MA

Steve....

Has there been any addi= tional information regarding this event?

Thanks,
Frank Acker
=
From: Boczenowski, Steve [sboczen= o@MITRE.ORG]
Sent: Tuesday, March 20, 2012 16:38
To: OVAL-DEVELOPER-LIS= T@LISTS.MITRE.ORG
Subject: [OVAL-DEVELOPER-LIST] Security Aut= omation Developer Days: Summer 2012 at MITRE in Bedford, MA
Save the Date: we= ek 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 = MIT= RE Corporation
= ;     Office: (781) 271-7682
      Cell: (978) 302-3849=
     sboczeno@mitre.org

To uns= ubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with SIGNOFF OVAL-DEVELOPER-LIST in the BO= DY 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@LI= STS.MITRE.ORG.
To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with S= IGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficul= ties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG.
= --_000_D7A0423E5E193F40BE6E94126930C4930B9BA83FFDMBCLUSTERxcha_-- From lnunez@c3isecurity.com Fri Jun 15 12:33:51 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB70411E80F9 for ; Fri, 15 Jun 2012 12:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQvSqZHm9ctE for ; Fri, 15 Jun 2012 12:33:46 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8969811E80F6 for ; Fri, 15 Jun 2012 12:33:46 -0700 (PDT) Received: by yhq56 with SMTP id 56so3062195yhq.31 for ; Fri, 15 Jun 2012 12:33:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=NGXmN4/8kZgOag5WwnldGnCOy7cqKwsbINrIwIaHsg8=; b=C2dqeBM9We1svVpMFGQ+yUUN6MMNC9f6WyQI6wwU4TS0Qo6cZeZO3iK9iAq0AN2gQC LcTzJxXGBZujF87FtJQKhY76276Nrgk6ZxnJudJep/QM5wrOC2EdztVH4eQEQaRFBP9L Q0G5xeTIOvqT5dng/MEa27ata8Hj4zLF3cLdsblAcgKuGVi1XSRuTy+knBTBYpgdubnh pX6d0BfvMAVGXp1H3jBqNmwJDw7cMcEda5UjwZRoDnkaY1wQmZdrV5VDmExtmlatAI4T j4oIa2Bi4SrFYbSseIaFG27fu8OUZKlqQZCl6OFDLCFl6XP7Bk+UiWFNKVM1m4KiSHtF Gp7w== Received: by 10.101.18.16 with SMTP id v16mr2924844ani.79.1339788824531; Fri, 15 Jun 2012 12:33:44 -0700 (PDT) Received: from [192.168.1.37] (cpe-066-057-081-254.nc.res.rr.com. [66.57.81.254]) by mx.google.com with ESMTPS id i16sm17434388anm.12.2012.06.15.12.33.42 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Jun 2012 12:33:43 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_6240EF91-60C2-4BA3-ABE4-7EB0B936FC78" From: Luis Nunez In-Reply-To: Date: Fri, 15 Jun 2012 15:33:43 -0400 Message-Id: <34425F2D-4172-4E61-89B8-00AD6BB6462E@c3isecurity.com> References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov> <00a801cd4a69$aba5be40$02f13ac0$@secpod.com> To: "Waltermire, David A." X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQlA9wGy68zySTC2bthP1v+SbhL1X+3ohuHjwdE7a7B3ONKRqKxW47kooD1nTEOUYMQrq/Ft Cc: SCAP-DEV , "bchandra@secpod.com" , "sacm@ietf.org" Subject: Re: [sacm] Request for participants - Content Repository Specification Development X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol $SCAP$." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 19:33:51 -0000 --Apple-Mail=_6240EF91-60C2-4BA3-ABE4-7EB0B936FC78 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1250 here is the faq with some samples http://scaprepo.com/faq.html cve access complexity high all vulnerabilities from jan 2011 -ln On Jun 15, 2012, at 3:23 PM, Waltermire, David A. wrote: > I am not sure how to use the search page properly. Would you please = provide some example searches? > =20 > Sincerely, > Dave > =20 > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf = Of Chandrashekhar B > Sent: Thursday, June 14, 2012 4:10 PM > To: SCAP-DEV; sacm@ietf.org > Subject: Re: [sacm] Request for participants - Content Repository = Specification Development > =20 > We have hosted our SCAP Content Repository at www.scaprepo.com. = Feedback is certainly appreciated. A simple web service interface will = be published soon. > =20 > Chandra. > =20 > From: scap-dev@nist.gov [mailto:scap-dev@nist.gov] On Behalf Of = Kent_Landfield@mcafee.com > Sent: Friday, May 11, 2012 10:14 PM > To: Multiple recipients of list > Subject: Request for participants - Content Repository Specification = Development > =20 > Mike I love it when you tee something up like that=85. ;-) Thank you. = ;) > =20 > Mike wrote:=20 > 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=85 > =20 > 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. ;) > =20 > 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.=20 > =20 > 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. ;) > =20 > So here is what I am thinking=85 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.=20 > =20 > Mike, to your point that we need someone to build one first=85 That = has happened already. I have one as do other vendors but what we don=92t = 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. =20 > =20 > TO THAT END=85. > =20 > 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.=20 > =20 > Thanks! > =20 > Kent Landfield > Director Content Strategy, Architecture and Standards >=20 > McAfee | An Intel Company > 5000 Headquarters Dr. > Plano, Texas 75024 >=20 > Direct: +1.972.963.7096=20 > Mobile: +1.817.637.8026 > Web: www.mcafee.com > =20 > From: , Michael A > To: David Waltermire , SCAP-DEV = , "sacm@ietforg" > Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation = Developer Days: Summer 2012 at MITRE in Bedford, MA > =20 > 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. > =20 > 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=85 > =20 > -Mike=20 > =20 > From: Waltermire, David A. [mailto:david.waltermire@nist.gov]=20 > 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 > =20 > Mike, > =20 > What about having webinars in-place of the 30 minute briefs? > =20 > 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. > =20 > 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. > =20 > Remediation is a topic near and dear to my heart. I too would like to = see it move forward. > =20 > 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). > =20 > Here are the links: > =20 > http://csrc.nist.gov/publications/PubsDrafts.html > http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7848 > =20 > 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. > =20 > I am also looking forward to the discussions at the conference. It = has been too long. > =20 > Sincerely, > Dave > =20 > From: Kinney, Michael A [mailto:m.kinne@radium.ncsc.mil]=20 > 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 > =20 > Kent, > =20 > It=92s good to read your thoughts, and a realistic actionable approach = is indeed needed Since all the activity hasn=92t been on the lists a = brief 1=8E2 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. > =20 > 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=92ve 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=92m not sure = a specification will solve that problem. > =20 > 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. > =20 > Remediation is stalled but I=92m 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. > =20 > 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. > =20 > 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=92t think that a move to internationalization = should impede efforts to move forward with use cases. > =20 > I look forward to talking with you at the conference. > =20 > v/r > =20 > 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 > =20 > =20 > =20 > 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 > =20 > Kent, > =20 > 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 =93on deck=94 if = all the objectives are reached and we complete all the scheduled = sessions early. > =20 > Thoughts? > =20 > Sincerely, > =20 > David Waltermire > SCAP Architect > National Institute of Standards and Technology > (301) 975-3390 > david.waltermire@nist.gov > =20 > 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 > =20 > All, > =20 > I would like to discuss the format for the SCAP Developer Days that = seems to be listed below. > =20 > 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. > =20 > 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. > =20 > 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. > Presentations are sent out to the attendees and the lists a week in = advance > Status for any effort is limited to 30 minutes > Focused brainstorming time should be established for certain areas = that need real work by the community > Efforts to be discussed should be based on needs of the security = automation space to move existing efforts to completion. > For example: > =20 > 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. > =20 > 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 +=85) 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. > =20 > 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. > =20 > I am really disappointed that Remediation is not on the list below=85 = 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. > =20 > 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=85. We need this discussed. > =20 > 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. > =20 > Thanks. > =20 > Kent Landfield > Director Content Strategy, Architecture and Standards >=20 > McAfee | An Intel Company > 5000 Headquarters Dr. > Plano, Texas 75024 >=20 > Direct: +1.972.963.7096=20 > Mobile: +1.817.637.8026 > Web: www.mcafee.com > =20 > From: , Steve > Reply-To: "OVAL Developer List (Closed Public Discussion)" = > To: "OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG" = > Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: = Summer 2012 at MITRE in Bedford, MA > =20 > Frank; > =20 > We hope to have the registration site up next week. The event will be = during the week of July 9 =96 starting Monday at 10:00 AM and ending on = Friday at 12:00. > =20 > Meanwhile, we are working on the agenda and are currently considering = this list of topics: > =20 > 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 > =20 > Steve > =20 > From: Frank Lindsay Acker [mailto:afrank@NOVA.EDU]=20 > 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 > =20 > Steve.... >=20 > Has there been any additional information regarding this event? >=20 > 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 >=20 > Save the Date: week of July 9, 2012 > =20 > This year=92s MITRE-hosted Security Automation Developer Days event = will be held during the week of July 9, 2012 at MITRE=92s facility in = Bedford, MA. > =20 > Details to follow. > =20 > Regards, > Steve > =20 > ______________________________________________ > Stephen P. Boczenowski > The MITRE Corporation > Office: (781) 271-7682 > Cell: (978) 302-3849 > sboczeno@mitre.org > =20 > 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 --Apple-Mail=_6240EF91-60C2-4BA3-ABE4-7EB0B936FC78 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1250
here is the faq with some samples http://scaprepo.com/faq.html

cve access complexity = high
all vulnerabilities from jan = 2011

I am not sure how to use the search page properly. = Would you please provide some example = searches?

Sincerely,

From: sacm-bounces@ietf.org = [mailto:sacm-bounces@ietf.org] On Behalf Of Chandrashekhar = B
Sent: Thursday, June 14, 2012 = 4:10 PM
To: SCAP-DEV; sacm@ietf.org
Subject: Re: [sacm] Request for = participants - Content Repository Specification = Development
We have hosted our SCAP Content Repository at www.scaprepo.com. Feedback is certainly appreciated. A = simple web service interface will be published = soon.

Chandra.

From: scap-dev@nist.gov [mailto:scap-dev@nist.gov] On Behalf Of  Friday, May 11, 2012 10:14 = PM
To: Multiple recipients of = list
Subject: Request for participants - = Content Repository Specification = Development
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=85

TO THAT END=85.

Kent LandfieldDirector 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:
From: <Kinney>, Michael A < David Waltermire <david.waltermire@nist.gov>, = SCAP-DEV <SCAP-DEV@nist.gov>, "sacm@ietforg" < 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=85 -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, = MAMike, 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:
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, = MAKent, It=92s good to read your thoughts, and a realistic actionable = approach is indeed needed Since all the activity hasn=92t been on = the lists a brief 1=8E2 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=92ve 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=92m 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=92m 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=92t 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.

Mike = Kinney
Project Director
Computer Network Defense Research and Technology (CND = R&T) Office9800 Savage = Road Ste 6767
Ft Meade, MD 20755-6767
Phone: = 410-854-4422
NSTS: 968-8886
Fax 410-854-4681
makinn2@nsa.gov
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, = MAKent, 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 =93on deck=94 if all the objectives are reached = and we complete all the scheduled sessions early.
Thoughts? Sincerely,David WaltermireSCAP ArchitectNational Institute of Standards and Technology
(301) 975-3390
From:scap-dev@nist.gov [mailto:scap-dev@nist.gov] On Behalf Of  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, MAI 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.
Presentations are sent out to the attendees = and the lists a week in advance
Status for any effort is limited to 30 = minutes
Focused = brainstorming time should be established for certain areas that need = real work by the community
Efforts to be discussed should be based on = needs of the security automation space to move existing efforts to = completion.

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 +=85) = 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=85 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=85. 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 LandfieldDirector 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:
From: <Boczenowski>, Steve < "OVAL Developer List = (Closed Public Discussion)" < " 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 =96 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/SWIDCEEXCCDFOVALASREnterprise OCILCybOX/MAECFederated Content Repository Spec
Endpoint Reporting for Continuous Monitoring and = Compliance (ERCC)MILETAXIIIF-M for SCAPIF-MAPSCAP ReleasesSCAP and IETFNETCONF 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
From: Boczenowski, Steve = [ Tuesday, March 20, 2012 = 16:38
To:  [OVAL-DEVELOPER-LIST] = Security Automation Developer Days: Summer 2012 at MITRE in Bedford, = MASave the Date: week of July 9, = 2012
This year=92s MITRE-hosted Security Automation Developer Days = event will be held during the week of July 9, 2012 at MITRE=92s facility = in Bedford, MA.

Details to follow.
Regards,
    Steve
Stephen P. = Boczenowski      The  Corporation
      Office: (781) = 271-7682
     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
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
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 sacm@ietf.org
https://www.ietf.org/ma= ilman/listinfo/sacm

= --Apple-Mail=_6240EF91-60C2-4BA3-ABE4-7EB0B936FC78-- From bchandra@secpod.com Sat Jun 16 13:34:17 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E4F21F850D for ; Sat, 16 Jun 2012 13:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.058 X-Spam-Level: X-Spam-Status: No, score=-0.058 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iS67hvJUOA1a for ; Sat, 16 Jun 2012 13:34:04 -0700 (PDT) Received: from cpanel23.interactivedns.com (cpanel23.interactivedns.com [184.173.122.2]) by ietfa.amsl.com (Postfix) with ESMTP id BA28E21F84EC for ; Sat, 16 Jun 2012 13:34:03 -0700 (PDT) Received: from [122.172.44.175] (port=26223 helo=hpPC) by cpanel23.interactivedns.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1Sfzgl-0003lq-E0; Sun, 17 Jun 2012 02:03:48 +0530 From: "Chandrashekhar B" To: "'Luis Nunez'" , "'Waltermire, David A.'" References: <15D0981C9BE53042A4C9D0F3D0B6826B2900F2@MSIS-GH1-UEA10.corp.nsa.gov> <00a801cd4a69$aba5be40$02f13ac0$@secpod.com> <34425F2D-4172-4E61-89B8-00AD6BB6462E@c3isecurity.com> In-Reply-To: <34425F2D-4172-4E61-89B8-00AD6BB6462E@c3isecurity.com> Date: Sun, 17 Jun 2012 02:03:38 +0530 Organization: SecPod Technologies Message-ID: <021101cd4bff$527d27d0$f7777770$@secpod.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0212_01CD4C2D.6C4394A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIK+AsmsxvscjAWr3S8jTQP4mAzmQJt5r4nAhycR3IBkntfiAI5rRVflj9S9sA= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel23.interactivedns.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - secpod.com X-Source: X-Source-Args: X-Source-Dir: Cc: 'SCAP-DEV' , sacm@ietf.org Subject: Re: [sacm] Request for participants - Content Repository Specification Development X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bchandra@secpod.com List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol $SCAP$." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2012 20:34:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0212_01CD4C2D.6C4394A0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable If you type "What to search", it points to the FQA page J =20 You can search based on all SCAP elements (Platform, product, class, = family, access complexity, availability, vendor.) which are identified as = keywords. There are additional handlers for like 'bulletin' is Microsoft security bulletins and 'benchmark' is compliance etc. If it doesn't fall into the above, it does text based search for queries like 'denial of service', = for example. I think we have covered large number of combinations that way.=20 =20 If you type in any ID, it'll directly go to the relation page. Good part = is it can learn new queries, please let us know if something doesn't work. =20 Thanks, Chandra.=20 =20 From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of = Luis Nunez Sent: Saturday, June 16, 2012 1:04 AM To: Waltermire, David A. Cc: SCAP-DEV; bchandra@secpod.com; sacm@ietf.org Subject: Re: [sacm] Request for participants - Content Repository Specification Development =20 here is the faq with some samples http://scaprepo.com/faq.html =20 cve access complexity high all vulnerabilities from jan 2011 -ln =20 =20 =20 On Jun 15, 2012, at 3:23 PM, Waltermire, David A. wrote: I am not sure how to use the search page properly. Would you please = provide some example searches? =20 Sincerely, Dave =20 From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Chandrashekhar B Sent: Thursday, June 14, 2012 4:10 PM To: SCAP-DEV; sacm@ietf.org Subject: Re: [sacm] Request for participants - Content Repository Specification Development =20 We have hosted our SCAP Content Repository at www.scaprepo.com. Feedback = is certainly appreciated. A simple web service interface will be published soon. =20 Chandra. =20 From: scap-dev@nist.gov [mailto:scap-dev@nist.gov] On Behalf Of Kent_Landfield@mcafee.com Sent: Friday, May 11, 2012 10:14 PM To: Multiple recipients of list Subject: Request for participants - Content Repository Specification Development =20 Mike I love it when you tee something up like that.. ;-) Thank you. ;) =20 Mike wrote:=20 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. =20 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. ;) =20 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.=20 =20 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. ;) =20 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.=20 =20 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. =20 =20 TO THAT END.. =20 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.=20 =20 Thanks! =20 Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096=20 Mobile: +1.817.637.8026 Web: www.mcafee.com =20 =20 From: , Michael A To: David Waltermire , SCAP-DEV , "sacm@ietforg " = Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA =20 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. =20 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. =20 -Mike=20 =20 From: Waltermire, David A. [mailto:david.waltermire@nist.gov]=20 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 =20 Mike, =20 What about having webinars in-place of the 30 minute briefs? =20 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. =20 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. =20 Remediation is a topic near and dear to my heart. I too would like to = see it move forward. =20 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). =20 Here are the links: =20 http://csrc.nist.gov/publications/PubsDrafts.html http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7848 =20 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. =20 I am also looking forward to the discussions at the conference. It has = been too long. =20 Sincerely, Dave =20 From: Kinney, Michael A [mailto:m.kinne@radium.ncsc.mil ]=20 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 =20 Kent, =20 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=AE2 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. =20 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. =20 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. =20 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. =20 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. =20 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. =20 I look forward to talking with you at the conference. =20 v/r =20 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 =20 =20 =20 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 =20 Kent, =20 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. =20 Thoughts? =20 Sincerely, =20 David Waltermire SCAP Architect National Institute of Standards and Technology (301) 975-3390 david.waltermire@nist.gov =20 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 =20 All, =20 I would like to discuss the format for the SCAP Developer Days that = seems to be listed below. =20 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. =20 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. =20 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: =20 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. =20 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. =20 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. =20 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. =20 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. =20 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. =20 Thanks. =20 Kent Landfield Director Content Strategy, Architecture and Standards McAfee | An Intel Company 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096=20 Mobile: +1.817.637.8026 Web: www.mcafee.com =20 =20 From: , Steve Reply-To: "OVAL Developer List (Closed Public Discussion)" To: "OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG" Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA =20 Frank; =20 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. =20 Meanwhile, we are working on the agenda and are currently considering = this list of topics: =20 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 =20 Steve =20 From: Frank Lindsay Acker [mailto:afrank@NOVA.EDU]=20 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 =20 Steve.... Has there been any additional information regarding this event? Thanks, Frank Acker _____ =20 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 =20 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. =20 Details to follow. =20 Regards, Steve =20 ______________________________________________ Stephen P. Boczenowski The MITRE Corporation Office: (781) 271-7682 Cell: (978) 302-3849 sboczeno@mitre.org =20 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 =20 ------=_NextPart_000_0212_01CD4C2D.6C4394A0 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
If you type “What to search”, it points to the FQA page = J

You can search based on all SCAP elements (Platform, product, class, = family, access complexity, availability, vendor…) which are = identified as keywords. There are additional handlers for like = ‘bulletin’ is Microsoft security bulletins and = ‘benchmark’ is compliance etc. If it doesn’t fall into = the above, it does text based search for queries like ’denial of = service’, for example. I think we have covered large number of = combinations that way.

If you type in any ID, it’ll directly go to the relation page. = Good part is it can learn new queries, please let us know if something = doesn’t work.

Thanks,
Chandra.

From:= = sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of = Luis Nunez
Sent: Saturday, June 16, 2012 1:04 = AM
To: Waltermire, David A.
Cc: SCAP-DEV; = bchandra@secpod.com; sacm@ietf.org
Subject: Re: [sacm] Request = for participants - Content Repository Specification = Development

here is = the faq with some samples http://scaprepo.com/faq.html

cve access complexity = high
all vulnerabilities from jan = 2011

=
-ln
=

On = Jun 15, 2012, at 3:23 PM, Waltermire, David A. = wrote:

I am not sure how to use the search page properly. Would you = please provide some example searches?=
=
Sincerely,=
Dave=
=
From:= sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.= org] On Behalf = Of Chandrashekhar = B
Sent: Thursday, June 14, 2012 4:10 = PM
To: SCAP-DEV; sacm@ietf.org
Subject: Re: [sacm] Request for = participants - Content Repository Specification Development=
=
We have hosted our SCAP Content Repository at www.scaprepo.com. Feedback is = certainly appreciated. A simple web service interface will be published = soon.=
=
Chandra.=
=
From:= scap-dev@nist.gov [mailto:scap-dev@nist.gov]= On Behalf Of Kent_Landfield@mcafee.comSent: Friday, = May 11, 2012 10:14 PM
To: Multiple recipients of = list
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=
=
From: <Kinney>, Michael A <m.kinne@radium.ncsc.mil>To: David = Waltermire <david.waltermire@nist.gov&g= t;, SCAP-DEV <SCAP-DEV@nist.gov>, "sacm@ietforg" <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.go= v]
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.ni= st.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=AE2 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=
=
=
=
= 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.comSent: 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.=
Presentatio= ns are sent out to the attendees and the lists a week in = advance
Status for = any effort is limited to 30 minutes
Focused = brainstorming time should be established for certain areas that need = real work by the community
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=
=
From: <Boczenowski>, Steve <sboczeno@MITRE.ORG>
Reply= -To: "OVAL = Developer List (Closed Public Discussion)" <OVAL-DEVELOPER-LIST@L= ISTS.MITRE.ORG>
To: "OVAL-DEVELOPER-LIST@L= ISTS.MITRE.ORG" <OVAL-DEVELOPER-LIST@L= ISTS.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@L= ISTS.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-DEVELOPE= R-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-DEVELOPE= R-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-DEVELOPE= R-LIST-request@LISTS.MITRE.ORG.=
_______________________________________________
sacm= mailing list
sacm@ietf.org
https://www.ietf.org/= mailman/listinfo/sacm

------=_NextPart_000_0212_01CD4C2D.6C4394A0-- From amontville@tripwire.com Thu Jun 28 09:04:17 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C0D21F85D8 for ; Thu, 28 Jun 2012 09:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0I+XK7mIT4A for ; Thu, 28 Jun 2012 09:04:17 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id 436A521F84E7 for ; Thu, 28 Jun 2012 09:04:13 -0700 (PDT) Received: from mail192-co1-R.bigfish.com (10.243.78.229) by CO1EHSOBE009.bigfish.com (10.243.66.72) with Microsoft SMTP Server id 14.1.225.23; Thu, 28 Jun 2012 16:02:25 +0000 Received: from mail192-co1 (localhost [127.0.0.1]) by mail192-co1-R.bigfish.com (Postfix) with ESMTP id B718148009A for ; Thu, 28 Jun 2012 16:02:25 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(zzzz1202hzzz2dh2a8h668h839h944he5bhf0ah) Received: from mail192-co1 (localhost.localdomain [127.0.0.1]) by mail192-co1 (MessageSwitch) id 1340899343613495_22420; Thu, 28 Jun 2012 16:02:23 +0000 (UTC) Received: from CO1EHSMHS027.bigfish.com (unknown [10.243.78.252]) by mail192-co1.bigfish.com (Postfix) with ESMTP id 8A7AE34004E for ; Thu, 28 Jun 2012 16:02:23 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by CO1EHSMHS027.bigfish.com (10.243.66.37) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 28 Jun 2012 16:02:23 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 28 Jun 2012 09:04:14 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Thu, 28 Jun 2012 09:03:23 -0700 From: Adam Montville To: "sacm@ietf.org" Thread-Topic: IETF 84 Thread-Index: AQHNVUeKYUpL4z7vTUubxQ1VahOvyA== Date: Thu, 28 Jun 2012 16:03:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: <6B0B64F1A32AB449B3D21CC3B202A3FB@tripwire.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: tripwire.com Subject: [sacm] IETF 84 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol $SCAP$." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 16:04:17 -0000 All: I've been out of this loop for a while, unfortunately. Hopefully, there is progress being made on the use cases and other efforts (I.e. content repository) that were proposed a couple of months ago. Can anyone tell me whether there is a scheduled meeting (side or otherwise) for SACM during IETF 84? If so, do we have any idea when it will be held? Regards, Adam From karen@scarfonecybersecurity.com Thu Jun 28 09:22:07 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 380EC21F8606 for ; Thu, 28 Jun 2012 09:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GWekcC8d5OJ for ; Thu, 28 Jun 2012 09:22:06 -0700 (PDT) Received: from mail-yw0-f42.google.com (mail-yw0-f42.google.com [209.85.213.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7642721F85E5 for ; Thu, 28 Jun 2012 09:22:04 -0700 (PDT) Received: by yhfq11 with SMTP id q11so2461152yhf.15 for ; Thu, 28 Jun 2012 09:22:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=3FYPnS1+453lD22G2BjtWE6ryPj+tZcWp+050gPaoDM=; b=CZ/Xw3dLhsTQUVxuX3Y58hP9f+OM01Qvp0I2FTOy4lxTQs2yLQOwvfDfMpV59tWBht rsGKMmt3QoeHagdFx+Su+YNPbWEZ+UQAQXHwi98fArJy27Xjg9MIuI1X9BHnojidj9jU nN/aiyJbozi8b58St6YSrBDiA71MBELSaq9WA+xLVeqqYTZZ4Od8vxdXaW5M52XgnKAF Jm1oi5DVk24JIdy20SDgxaJ17EyMEBVVxRgtxByHEKgg+ue7vxZQ+wc/eDCEYWDbXKbN N0rAlnzWVhWebCrBCYkLJmaP6E2rdJK26vZR1mjv0v3dx21nYVy7A+TXbvx/wr7Ftlc+ uYzw== MIME-Version: 1.0 Received: by 10.50.158.229 with SMTP id wx5mr352982igb.23.1340900523660; Thu, 28 Jun 2012 09:22:03 -0700 (PDT) Received: by 10.231.204.7 with HTTP; Thu, 28 Jun 2012 09:22:03 -0700 (PDT) In-Reply-To: References: Date: Thu, 28 Jun 2012 12:22:03 -0400 Message-ID: From: Karen Scarfone To: "sacm@ietf.org" Content-Type: multipart/alternative; boundary=14dae934062b64563904c38abbd5 X-Gm-Message-State: ALoCoQkf8chdHXEzrhwj0XCHBPR/9pT/BRgcx5ADamYj5O4uukcfTWBs3/rTBONgXG4OTAnopyEQ Subject: Re: [sacm] IETF 84 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol $SCAP$." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 16:22:07 -0000 --14dae934062b64563904c38abbd5 Content-Type: text/plain; charset=ISO-8859-1 I've gotten out of the loop on this as well. I'm still available to edit any documents being produced by this effort. Karen On Thu, Jun 28, 2012 at 12:03 PM, Adam Montville wrote: > All: > > I've been out of this loop for a while, unfortunately. Hopefully, there > is progress being made on the use cases and other efforts (I.e. content > repository) that were proposed a couple of months ago. > > Can anyone tell me whether there is a scheduled meeting (side or > otherwise) for SACM during IETF 84? If so, do we have any idea when it > will be held? > > Regards, > > Adam > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > -- Karen Scarfone, Principal Consultant, Scarfone Cybersecurity karen@scarfonecybersecurity.com (703)401-1018 --14dae934062b64563904c38abbd5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I've gotten out of the loop on this as well. I'm still available to= edit any documents being produced by this effort.

<= /div>
Karen

On Thu, Jun 28, 2012 at 1= 2:03 PM, Adam Montville <amontville@tripwire.com> wrot= e:

All:

I've been out of this loop for a while, unfortunately. =A0Hopefully, th= ere
is progress being made on the use cases and other efforts (I.e. content
repository) that were proposed a couple of months ago.

Can anyone tell me whether there is a scheduled meeting (side or
otherwise) for SACM during IETF 84? =A0If so, do we have any idea when it will be held?

Regards,

Adam

_______________________________________________
sacm mailing list
sacm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sacm

--
Karen Scarfo= ne, Principal Consultant, Scarfone Cybersecurity
karen@scarfonecybersecurity.c= om=A0=A0 (703)401-1018

--14dae934062b64563904c38abbd5-- From kathleen.moriarty@emc.com Thu Jun 28 09:39:30 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 764E621F850D for ; Thu, 28 Jun 2012 09:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlStEsV4FSWD for ; Thu, 28 Jun 2012 09:39:29 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 784B221F8503 for ; Thu, 28 Jun 2012 09:39:29 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5SGdM9s007838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2012 12:39:25 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Thu, 28 Jun 2012 12:39:10 -0400 Received: from mxhub03.corp.emc.com (mxhub03.corp.emc.com [10.254.141.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5SGd9Q8020849; Thu, 28 Jun 2012 12:39:09 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub03.corp.emc.com ([10.254.141.105]) with mapi; Thu, 28 Jun 2012 12:39:08 -0400 From: To: , Date: Thu, 28 Jun 2012 12:39:08 -0400 Thread-Topic: [sacm] IETF 84 Thread-Index: Ac1VSmbzmrl6YZQWRmaJIN8++JBeCgAAbR8w Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5063677821E3B4F81ACFB7905573F2403949B40MX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [sacm] IETF 84 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol $SCAP$." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 16:39:30 -0000 --_000_F5063677821E3B4F81ACFB7905573F2403949B40MX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for starting the thread, Adam and offering to help Karen! A few of us have been working to update the use case document that David Wa= ltermire circulated. We may need help here as I am not sure if we have con= tent for each of the use cases yet. I provided content to update use case = 5. The hope was to review the use cases in a side meeting and start looking at= a charter in support of the defined use cases. From there, we can figure = out what work is needed to support the use cases and charter. This would b= e used to set the milestones. Should we set a meeting for the Sunday again? Thank you, Kathleen From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Kar= en Scarfone Sent: Thursday, June 28, 2012 12:22 PM To: sacm@ietf.org Subject: Re: [sacm] IETF 84 I've gotten out of the loop on this as well. I'm still available to edit an= y documents being produced by this effort. Karen On Thu, Jun 28, 2012 at 12:03 PM, Adam Montville > wrote: All: I've been out of this loop for a while, unfortunately. Hopefully, there is progress being made on the use cases and other efforts (I.e. content repository) that were proposed a couple of months ago. Can anyone tell me whether there is a scheduled meeting (side or otherwise) for SACM during IETF 84? If so, do we have any idea when it will be held? Regards, Adam _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm -- Karen Scarfone, Principal Consultant, Scarfone Cybersecurity karen@scarfonecybersecurity.com (= 703)401-1018 --_000_F5063677821E3B4F81ACFB7905573F2403949B40MX15Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thanks fo= r starting the thread, Adam and offering to help Karen!

A few of us have been working to update the use case document th= at David Waltermire circulated. We may need help here as I am not sur= e if we have content for each of the use cases yet. I provided conten= t to update use case 5.

The hope was to revie= w the use cases in a side meeting and start looking at a charter in support= of the defined use cases. From there, we can figure out what work is= needed to support the use cases and charter. This would be used to s= et the milestones.
&n= bsp;
Should we set a meeting fo= r the Sunday again?

Thank you,
Kathleen

Fr= om: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of= Karen Scarfone
Sent: Thursday, June 28, 2012 12:22 PM
= To: sacm@ietf.org
Subject: Re: [sacm] IETF 84

= I've gotten out of the loop on this as well. I'm still available to edit an= y documents being produced by this effort.

Karen=
On Thu, Jun 28, 2012 at 12:03 PM, = Adam Montville <amontville@tripwire.com> wrote:
All:

I've been out of this loop for a while, unfortunately. &nbs= p;Hopefully, there
is progress being made on the use cases and other eff= orts (I.e. content
repository) that were proposed a couple of months ago= .

Can anyone tell me whether there is a scheduled meeting (side orotherwise) for SACM during IETF 84? If so, do we have any idea when= it
will be held?

Regards,

Adam

_______________= ________________________________
sacm mailing list
sacm@ietf.org
https://www.ietf.org/mailman/listinfo/sac= m

--
Karen Scarfone, Principal Consu= ltant, Scarfone Cybersecurity
karen@scarfonecybersecurity.com   = (703)401-1018
= --_000_F5063677821E3B4F81ACFB7905573F2403949B40MX15Acorpemccom_-- From david.waltermire@nist.gov Thu Jun 28 09:45:27 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDC521F850D for ; Thu, 28 Jun 2012 09:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.102 X-Spam-Level: X-Spam-Status: No, score=-5.102 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpZTPLYyX7pa for ; Thu, 28 Jun 2012 09:45:26 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 11B5121F8503 for ; Thu, 28 Jun 2012 09:45:25 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 28 Jun 2012 12:44:39 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Thu, 28 Jun 2012 12:44:57 -0400 From: "Waltermire, David A." To: "kathleen.moriarty@emc.com" , "karen@scarfonecybersecurity.com" , "sacm@ietf.org" Date: Thu, 28 Jun 2012 12:44:55 -0400 Thread-Topic: [sacm] IETF 84 Thread-Index: Ac1VSmbzmrl6YZQWRmaJIN8++JBeCgAAbR8wAABF5aA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D7A0423E5E193F40BE6E94126930C4930B9D8CA073MBCLUSTERxcha_" MIME-Version: 1.0 Subject: Re: [sacm] IETF 84 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol $SCAP$." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 16:45:27 -0000 --_000_D7A0423E5E193F40BE6E94126930C4930B9D8CA073MBCLUSTERxcha_ Content-Type: text/plain; charset="us-ascii" I think it would be valuable to have some discussion around the use cases and some initial concepts for the charter. Sunday would work for me. Sincerely, Dave From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of kathleen.moriarty@emc.com Sent: Thursday, June 28, 2012 12:39 PM To: karen@scarfonecybersecurity.com; sacm@ietf.org Subject: Re: [sacm] IETF 84 Thanks for starting the thread, Adam and offering to help Karen! A few of us have been working to update the use case document that David Waltermire circulated. We may need help here as I am not sure if we have content for each of the use cases yet. I provided content to update use case 5. The hope was to review the use cases in a side meeting and start looking at a charter in support of the defined use cases. From there, we can figure out what work is needed to support the use cases and charter. This would be used to set the milestones. Should we set a meeting for the Sunday again? Thank you, Kathleen From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Karen Scarfone Sent: Thursday, June 28, 2012 12:22 PM To: sacm@ietf.org Subject: Re: [sacm] IETF 84 I've gotten out of the loop on this as well. I'm still available to edit any documents being produced by this effort. Karen On Thu, Jun 28, 2012 at 12:03 PM, Adam Montville > wrote: All: I've been out of this loop for a while, unfortunately. Hopefully, there is progress being made on the use cases and other efforts (I.e. content repository) that were proposed a couple of months ago. Can anyone tell me whether there is a scheduled meeting (side or otherwise) for SACM during IETF 84? If so, do we have any idea when it will be held? Regards, Adam _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm -- Karen Scarfone, Principal Consultant, Scarfone Cybersecurity karen@scarfonecybersecurity.com (703)401-1018 --_000_D7A0423E5E193F40BE6E94126930C4930B9D8CA073MBCLUSTERxcha_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXMtYXNjaWkiPjxtZXRhIG5hbWU9R2VuZXJhdG9yIGNv bnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj48c3R5bGU+PCEtLQ0K LyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxl IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRp di5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi QmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxvb25U ZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9k eSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlv bjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SSB0aGluayBpdCB3 b3VsZCBiZSB2YWx1YWJsZSB0byBoYXZlIHNvbWUgZGlzY3Vzc2lvbiBhcm91bmQgdGhlIHVzZSBj YXNlcyBhbmQgc29tZSBpbml0aWFsIGNvbmNlcHRzIGZvciB0aGUgY2hhcnRlci4mbmJzcDsgU3Vu ZGF5IHdvdWxkIHdvcmsgZm9yIG1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5TaW5jZXJlbHks PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPkRhdmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+ PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiInPiBzYWNtLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzYWNt LWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+a2F0aGxlZW4ubW9yaWFydHlA ZW1jLmNvbTxicj48Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bmUgMjgsIDIwMTIgMTI6MzkgUE08 YnI+PGI+VG86PC9iPiBrYXJlbkBzY2FyZm9uZWN5YmVyc2VjdXJpdHkuY29tOyBzYWNtQGlldGYu b3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW3NhY21dIElFVEYgODQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoYW5rcyBmb3Igc3Rh cnRpbmcgdGhlIHRocmVhZCwgQWRhbSBhbmQgb2ZmZXJpbmcgdG8gaGVscCBLYXJlbiE8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPkEgZmV3IG9mIHVzIGhhdmUgYmVlbiB3b3JraW5nIHRvIHVwZGF0ZSB0aGUg dXNlIGNhc2UgZG9jdW1lbnQgdGhhdCBEYXZpZCBXYWx0ZXJtaXJlIGNpcmN1bGF0ZWQuJm5ic3A7 IFdlIG1heSBuZWVkIGhlbHAgaGVyZSBhcyBJIGFtIG5vdCBzdXJlIGlmIHdlIGhhdmUgY29udGVu dCBmb3IgZWFjaCBvZiB0aGUgdXNlIGNhc2VzIHlldC4mbmJzcDsgSSBwcm92aWRlZCBjb250ZW50 IHRvIHVwZGF0ZSB1c2UgY2FzZSA1LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhlIGhvcGUgd2FzIHRv IHJldmlldyB0aGUgdXNlIGNhc2VzIGluIGEgc2lkZSBtZWV0aW5nIGFuZCBzdGFydCBsb29raW5n IGF0IGEgY2hhcnRlciBpbiBzdXBwb3J0IG9mIHRoZSBkZWZpbmVkIHVzZSBjYXNlcy4mbmJzcDsg RnJvbSB0aGVyZSwgd2UgY2FuIGZpZ3VyZSBvdXQgd2hhdCB3b3JrIGlzIG5lZWRlZCB0byBzdXBw b3J0IHRoZSB1c2UgY2FzZXMgYW5kIGNoYXJ0ZXIuJm5ic3A7IFRoaXMgd291bGQgYmUgdXNlZCB0 byBzZXQgdGhlIG1pbGVzdG9uZXMuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5TaG91bGQgd2Ugc2V0IGEg bWVldGluZyBmb3IgdGhlIFN1bmRheSBhZ2Fpbj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoYW5rIHlv dSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+S2F0aGxlZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYg c3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9t YSIsInNhbnMtc2VyaWYiJz4gPGEgaHJlZj0ibWFpbHRvOnNhY20tYm91bmNlc0BpZXRmLm9yZyI+ c2FjbS1ib3VuY2VzQGlldGYub3JnPC9hPiA8YSBocmVmPSJtYWlsdG86W21haWx0bzpzYWNtLWJv dW5jZXNAaWV0Zi5vcmddIj5bbWFpbHRvOnNhY20tYm91bmNlc0BpZXRmLm9yZ108L2E+IDxiPk9u IEJlaGFsZiBPZiA8L2I+S2FyZW4gU2NhcmZvbmU8YnI+PGI+U2VudDo8L2I+IFRodXJzZGF5LCBK dW5lIDI4LCAyMDEyIDEyOjIyIFBNPGJyPjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnNhY21A aWV0Zi5vcmciPnNhY21AaWV0Zi5vcmc8L2E+PGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW3NhY21d IElFVEYgODQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5JJ3ZlIGdvdHRlbiBvdXQgb2Yg dGhlIGxvb3Agb24gdGhpcyBhcyB3ZWxsLiBJJ20gc3RpbGwgYXZhaWxhYmxlIHRvIGVkaXQgYW55 IGRvY3VtZW50cyBiZWluZyBwcm9kdWNlZCBieSB0aGlzIGVmZm9ydC48bzpwPjwvbzpwPjwvcD48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPkthcmVuPG86cD48L286cD48 L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+T24gVGh1LCBKdW4gMjgsIDIwMTIgYXQgMTI6MDMg UE0sIEFkYW0gTW9udHZpbGxlICZsdDs8YSBocmVmPSJtYWlsdG86YW1vbnR2aWxsZUB0cmlwd2ly ZS5jb20iIHRhcmdldD0iX2JsYW5rIj5hbW9udHZpbGxlQHRyaXB3aXJlLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5BbGw6PGJyPjxicj5JJ3ZlIGJl ZW4gb3V0IG9mIHRoaXMgbG9vcCBmb3IgYSB3aGlsZSwgdW5mb3J0dW5hdGVseS4gJm5ic3A7SG9w ZWZ1bGx5LCB0aGVyZTxicj5pcyBwcm9ncmVzcyBiZWluZyBtYWRlIG9uIHRoZSB1c2UgY2FzZXMg YW5kIG90aGVyIGVmZm9ydHMgKEkuZS4gY29udGVudDxicj5yZXBvc2l0b3J5KSB0aGF0IHdlcmUg cHJvcG9zZWQgYSBjb3VwbGUgb2YgbW9udGhzIGFnby48YnI+PGJyPkNhbiBhbnlvbmUgdGVsbCBt ZSB3aGV0aGVyIHRoZXJlIGlzIGEgc2NoZWR1bGVkIG1lZXRpbmcgKHNpZGUgb3I8YnI+b3RoZXJ3 aXNlKSBmb3IgU0FDTSBkdXJpbmcgSUVURiA4ND8gJm5ic3A7SWYgc28sIGRvIHdlIGhhdmUgYW55 IGlkZWEgd2hlbiBpdDxicj53aWxsIGJlIGhlbGQ/PGJyPjxicj5SZWdhcmRzLDxicj48YnI+QWRh bTxicj48YnI+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPnNhY20gbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzpzYWNtQGlldGYub3Jn Ij5zYWNtQGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NhY20iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NhY208L2E+PG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxicj48YnIgY2xlYXI9YWxsPjxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPi0tIDxicj5LYXJlbiBTY2FyZm9uZSwgUHJpbmNpcGFs IENvbnN1bHRhbnQsIFNjYXJmb25lIEN5YmVyc2VjdXJpdHk8YnI+PGEgaHJlZj0ibWFpbHRvOmth cmVuQHNjYXJmb25lY3liZXJzZWN1cml0eS5jb20iIHRhcmdldD0iX2JsYW5rIj5rYXJlbkBzY2Fy Zm9uZWN5YmVyc2VjdXJpdHkuY29tPC9hPiZuYnNwOyZuYnNwOyAoNzAzKTQwMS0xMDE4PG86cD48 L286cD48L3A+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_D7A0423E5E193F40BE6E94126930C4930B9D8CA073MBCLUSTERxcha_-- From Kent_Landfield@mcafee.com Thu Jun 28 09:50:27 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F5321F850D for ; Thu, 28 Jun 2012 09:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11rlM2nUcVDX for ; Thu, 28 Jun 2012 09:50:26 -0700 (PDT) Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB3421F84FE for ; Thu, 28 Jun 2012 09:50:26 -0700 (PDT) Received: from DALEXHT2.corp.nai.org (unknown [10.64.5.52]) by dalsmrelay2.nai.com with smtp id 04f1_5aff_5e57bd0b_4ff6_472f_bb82_99d2b1308ede; Thu, 28 Jun 2012 11:50:20 -0500 Received: from AMERDALEXMB1.corp.nai.org ([fe80::b534:4a0d:1289:2d2d]) by DALEXHT2.corp.nai.org ([::1]) with mapi; Thu, 28 Jun 2012 11:48:11 -0500 From: To: , , Date: Thu, 28 Jun 2012 11:48:59 -0500 Thread-Topic: [sacm] IETF 84 Thread-Index: Ac1VTcz198HzCJ3pTVKH8N9bbnxMmg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC11F4A436422kentlandfieldmcafeecom_" MIME-Version: 1.0 Subject: Re: [sacm] IETF 84 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol $SCAP$." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 16:50:28 -0000 --_000_CC11F4A436422kentlandfieldmcafeecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Personally I'd rather not do Sunday if we can. It worked but we had a coupl= e people that wanted to be there that did not arrive until after the meetin= g and could not listen in as they were in transit at the time. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Kathleen Moriarty > To: "karen@scarfonecybersecurity.com" = >, "sacm@ietf.org" > Subject: Re: [sacm] IETF 84 Thanks for starting the thread, Adam and offering to help Karen! A few of us have been working to update the use case document that David Wa= ltermire circulated. We may need help here as I am not sure if we have con= tent for each of the use cases yet. I provided content to update use case = 5. The hope was to review the use cases in a side meeting and start looking at= a charter in support of the defined use cases. From there, we can figure = out what work is needed to support the use cases and charter. This would b= e used to set the milestones. Should we set a meeting for the Sunday again? Thank you, Kathleen From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Karen Scarfone Sent: Thursday, June 28, 2012 12:22 PM To: sacm@ietf.org Subject: Re: [sacm] IETF 84 I've gotten out of the loop on this as well. I'm still available to edit an= y documents being produced by this effort. Karen On Thu, Jun 28, 2012 at 12:03 PM, Adam Montville > wrote: All: I've been out of this loop for a while, unfortunately. Hopefully, there is progress being made on the use cases and other efforts (I.e. content repository) that were proposed a couple of months ago. Can anyone tell me whether there is a scheduled meeting (side or otherwise) for SACM during IETF 84? If so, do we have any idea when it will be held? Regards, Adam _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm -- Karen Scarfone, Principal Consultant, Scarfone Cybersecurity karen@scarfonecybersecurity.com (= 703)401-1018 --_000_CC11F4A436422kentlandfieldmcafeecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Pers= onally I'd rather not do Sunday if we can. It worked but we had a couple pe= ople that wanted to be there that did not arrive until after the meeting an= d could not listen in as they were in transit at the time.

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com

From: Kathleen Moriarty <kathleen.moriarty@emc.com>
= To: "karen@scarfonecybersecurity.com" <karen@scarfonecybersecurity.com&= gt;, "sacm@ietf.org" <sacm@ietf.org>
Subject: Re: [sacm] IETF 84

Thanks for starting the thread, Adam and offering to help Karen!

A few of us have been = working to update the use case document that David Waltermire circulated.&n= bsp; We may need help here as I am not sure if we have content for each of the use cases yet. I provided content to update use case 5.<= o:p>

The hope was to rev= iew the use cases in a side meeting and start looking at a charter in suppo= rt of the defined use cases. From there, we can figure out what work is needed to support the use cases and charter. This would be u= sed to set the milestones.

Should we set a meeting for the Sunday again?
=

Thank you,
Kathleen

From: sacm-bounces@ie= tf.org [mailto:sacm-bounces@ie= tf.org] On Behalf Of Karen Scarfone
Sent: Thursday, June 28, 2012 = 12:22 PM
To: sacm@ietf.orgSubject: Re: [sacm] IETF 84

I've gotten out of = the loop on this as well. I'm still available to edit any documents being p= roduced by this effort.
&nbs= p;

Karen
On Thu, Jun 28, 2012 at 12:03 PM, Adam Montvi= lle <amontv= ille@tripwire.com> wrote:
All:<= br>
I've been out of this loop for a while, unfortunately. Hopefully, the= re
is progress being made on the use cases and other efforts (I.e. content
= repository) that were proposed a couple of months ago.

Can anyone tell me whether there is a scheduled meeting (side or
otherwise) for SACM during IETF 84? If so, do we have any idea when i= t
will be held?

Regards,

Adam

_______________________________________________
sacm mailing list
sacm@ietf.org
= ht= tps://www.ietf.org/mailman/listinfo/sacm

--
Karen Scarfone, Principal Consultant, Scarfone Cybersecurity
karen@scarfonecyb= ersecurity.com   (703)401-1018
--_000_CC11F4A436422kentlandfieldmcafeecom_-- From amontville@tripwire.com Thu Jun 28 09:52:46 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480D621F84E7 for ; Thu, 28 Jun 2012 09:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKleRbpneprc for ; Thu, 28 Jun 2012 09:52:39 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 03E2521F8540 for ; Thu, 28 Jun 2012 09:52:39 -0700 (PDT) Received: from mail61-tx2-R.bigfish.com (10.9.14.240) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.23; Thu, 28 Jun 2012 16:50:51 +0000 Received: from mail61-tx2 (localhost [127.0.0.1]) by mail61-tx2-R.bigfish.com (Postfix) with ESMTP id A812360332; Thu, 28 Jun 2012 16:50:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: -33 X-BigFish: VPS-33(zz98dI9371I9f17R148cIzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h944he5bhf0ah) Received: from mail61-tx2 (localhost.localdomain [127.0.0.1]) by mail61-tx2 (MessageSwitch) id 1340902250133613_5480; Thu, 28 Jun 2012 16:50:50 +0000 (UTC) Received: from TX2EHSMHS044.bigfish.com (unknown [10.9.14.249]) by mail61-tx2.bigfish.com (Postfix) with ESMTP id 1098E40052; Thu, 28 Jun 2012 16:50:50 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by TX2EHSMHS044.bigfish.com (10.9.99.144) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 28 Jun 2012 16:50:48 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 28 Jun 2012 09:53:25 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Thu, 28 Jun 2012 09:52:34 -0700 From: Adam Montville To: "Kent_Landfield@McAfee.com" , "kathleen.moriarty@emc.com" , "karen@scarfonecybersecurity.com" , "sacm@ietf.org" Thread-Topic: [sacm] IETF 84 Thread-Index: AQHNVUeKYUpL4z7vTUubxQ1VahOvyJcQXxeAgAAExgCAAALAgP//i6SA Date: Thu, 28 Jun 2012 16:52:33 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [172.16.97.29] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: <8B011A6C42221F46B3FA7ED31AC855F0@tripwire.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: tripwire.com Subject: Re: [sacm] IETF 84 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol $SCAP$." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 16:52:46 -0000 I would also prefer a day other than Sunday, though I can make that work if= needed. Adam From: kent_landfield > Date: Thursday, June 28, 2012 9:48 AM To: "kathleen.moriarty@emc.com" >, "karen@scarfonecybers= ecurity.com" >, "sacm@ietf.org" > Subject: Re: [sacm] IETF 84 Personally I'd rather not do Sunday if we can. It worked but we had a coupl= e people that wanted to be there that did not arrive until after the meetin= g and could not listen in as they were in transit at the time. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Kathleen Moriarty > To: "karen@scarfonecybersecurity.com" = >, "sacm@ietf.org" > Subject: Re: [sacm] IETF 84 Thanks for starting the thread, Adam and offering to help Karen! A few of us have been working to update the use case document that David Wa= ltermire circulated. We may need help here as I am not sure if we have con= tent for each of the use cases yet. I provided content to update use case = 5. The hope was to review the use cases in a side meeting and start looking at= a charter in support of the defined use cases. From there, we can figure = out what work is needed to support the use cases and charter. This would b= e used to set the milestones. Should we set a meeting for the Sunday again? Thank you, Kathleen From:sacm-bounces@ietf.org [mailto:sacm-bounc= es@ietf.org] On Behalf Of Karen Scarfone Sent: Thursday, June 28, 2012 12:22 PM To: sacm@ietf.org Subject: Re: [sacm] IETF 84 I've gotten out of the loop on this as well. I'm still available to edit an= y documents being produced by this effort. Karen On Thu, Jun 28, 2012 at 12:03 PM, Adam Montville > wrote: All: I've been out of this loop for a while, unfortunately. Hopefully, there is progress being made on the use cases and other efforts (I.e. content repository) that were proposed a couple of months ago. Can anyone tell me whether there is a scheduled meeting (side or otherwise) for SACM during IETF 84? If so, do we have any idea when it will be held? Regards, Adam _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm -- Karen Scarfone, Principal Consultant, Scarfone Cybersecurity karen@scarfonecybersecurity.com (= 703)401-1018 From kathleen.moriarty@emc.com Thu Jun 28 09:59:16 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729D421F8540 for ; Thu, 28 Jun 2012 09:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeuUsxBnIdOL for ; Thu, 28 Jun 2012 09:59:15 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3E921F853D for ; Thu, 28 Jun 2012 09:59:14 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5SGxD7e024372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2012 12:59:14 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Thu, 28 Jun 2012 12:58:59 -0400 Received: from mxhub30.corp.emc.com (mxhub30.corp.emc.com [128.222.70.170]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5SGwvIh005326; Thu, 28 Jun 2012 12:58:57 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub30.corp.emc.com ([128.222.70.170]) with mapi; Thu, 28 Jun 2012 12:58:56 -0400 From: To: , , , Date: Thu, 28 Jun 2012 12:58:55 -0400 Thread-Topic: [sacm] IETF 84 Thread-Index: AQHNVUeKYUpL4z7vTUubxQ1VahOvyJcQXxeAgAAExgCAAALAgP//i6SAgAAAr7A= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [sacm] IETF 84 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol $SCAP$." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 16:59:16 -0000 OK, with a side-meeting, we are restricted to times that do not conflict wi= th other meetings. Evenings or early morning could work. We do have a soc= ial at this meeting, so Tuesday night is out. I think we need to avoid the= plenary nights as well. When we held the first MILE meeting, it was after= one of the plenary meetings and that was hard as it was late and people wa= nted to eat. I don't see an agenda posted yet, so we'll need to work around plenary meet= ings once they are scheduled if we meet one evening. I agree with Dave on the agenda. Thanks, Kathleen -----Original Message----- From: Adam Montville [mailto:amontville@tripwire.com]=20 Sent: Thursday, June 28, 2012 12:53 PM To: Kent_Landfield@McAfee.com; Moriarty, Kathleen; karen@scarfonecybersecur= ity.com; sacm@ietf.org Subject: Re: [sacm] IETF 84 I would also prefer a day other than Sunday, though I can make that work if= needed. Adam From: kent_landfield > Date: Thursday, June 28, 2012 9:48 AM To: "kathleen.moriarty@emc.com" >, "karen@scarfonecybers= ecurity.com" >, "sacm@ietf.org" > Subject: Re: [sacm] IETF 84 Personally I'd rather not do Sunday if we can. It worked but we had a coupl= e people that wanted to be there that did not arrive until after the meetin= g and could not listen in as they were in transit at the time. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Kathleen Moriarty > To: "karen@scarfonecybersecurity.com" = >, "sacm@ietf.org" > Subject: Re: [sacm] IETF 84 Thanks for starting the thread, Adam and offering to help Karen! A few of us have been working to update the use case document that David Wa= ltermire circulated. We may need help here as I am not sure if we have con= tent for each of the use cases yet. I provided content to update use case = 5. The hope was to review the use cases in a side meeting and start looking at= a charter in support of the defined use cases. From there, we can figure = out what work is needed to support the use cases and charter. This would b= e used to set the milestones. Should we set a meeting for the Sunday again? Thank you, Kathleen From:sacm-bounces@ietf.org [mailto:sacm-bounc= es@ietf.org] On Behalf Of Karen Scarfone Sent: Thursday, June 28, 2012 12:22 PM To: sacm@ietf.org Subject: Re: [sacm] IETF 84 I've gotten out of the loop on this as well. I'm still available to edit an= y documents being produced by this effort. Karen On Thu, Jun 28, 2012 at 12:03 PM, Adam Montville > wrote: All: I've been out of this loop for a while, unfortunately. Hopefully, there is progress being made on the use cases and other efforts (I.e. content repository) that were proposed a couple of months ago. Can anyone tell me whether there is a scheduled meeting (side or otherwise) for SACM during IETF 84? If so, do we have any idea when it will be held? Regards, Adam _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm -- Karen Scarfone, Principal Consultant, Scarfone Cybersecurity karen@scarfonecybersecurity.com (= 703)401-1018 From bakerj@mitre.org Thu Jun 28 09:59:24 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 429F921F8599 for ; Thu, 28 Jun 2012 09:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qsi0FTs5i6RO for ; Thu, 28 Jun 2012 09:59:23 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 46E9821F854E for ; Thu, 28 Jun 2012 09:59:23 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7400521B0FE0; Thu, 28 Jun 2012 12:59:22 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 624DB21B0410; Thu, 28 Jun 2012 12:59:22 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.107]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0283.003; Thu, 28 Jun 2012 12:59:21 -0400 From: "Baker, Jon" To: "kathleen.moriarty@emc.com" , "karen@scarfonecybersecurity.com" , "sacm@ietf.org" Thread-Topic: [sacm] IETF 84 Thread-Index: AQHNVUeKYUpL4z7vTUubxQ1VahOvyJcQLMyAgAAExgD//8HKoA== Date: Thu, 28 Jun 2012 16:59:21 +0000 Message-ID: <6C1C15D8B5510B4B8FF132B10D38651301DEE548@IMCMBX03.MITRE.ORG> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.58] Content-Type: multipart/alternative; boundary="_000_6C1C15D8B5510B4B8FF132B10D38651301DEE548IMCMBX03MITREOR_" MIME-Version: 1.0 Subject: Re: [sacm] IETF 84 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol $SCAP$." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 16:59:24 -0000 --_000_6C1C15D8B5510B4B8FF132B10D38651301DEE548IMCMBX03MITREOR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Does this conversation need to wait until the ietf meeting? Given that many of the participants will be at developer days in two weeks = maybe some discussion could be held afterhours there? This might allow for a more mature draft to be discussed at the IETF meetin= g a few weeks later. Jon =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jonathan O. Baker G022 - IA Industry Collaboration The MITRE Corporation Email: bakerj@mitre.org From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of kat= hleen.moriarty@emc.com Sent: Thursday, June 28, 2012 12:39 PM To: karen@scarfonecybersecurity.com; sacm@ietf.org Subject: Re: [sacm] IETF 84 Thanks for starting the thread, Adam and offering to help Karen! A few of us have been working to update the use case document that David Wa= ltermire circulated. We may need help here as I am not sure if we have con= tent for each of the use cases yet. I provided content to update use case = 5. The hope was to review the use cases in a side meeting and start looking at= a charter in support of the defined use cases. From there, we can figure = out what work is needed to support the use cases and charter. This would b= e used to set the milestones. Should we set a meeting for the Sunday again? Thank you, Kathleen From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Karen Sca= rfone Sent: Thursday, June 28, 2012 12:22 PM To: sacm@ietf.org Subject: Re: [sacm] IETF 84 I've gotten out of the loop on this as well. I'm still available to edit an= y documents being produced by this effort. Karen On Thu, Jun 28, 2012 at 12:03 PM, Adam Montville > wrote: All: I've been out of this loop for a while, unfortunately. Hopefully, there is progress being made on the use cases and other efforts (I.e. content repository) that were proposed a couple of months ago. Can anyone tell me whether there is a scheduled meeting (side or otherwise) for SACM during IETF 84? If so, do we have any idea when it will be held? Regards, Adam _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm -- Karen Scarfone, Principal Consultant, Scarfone Cybersecurity karen@scarfonecybersecurity.com (= 703)401-1018 --_000_6C1C15D8B5510B4B8FF132B10D38651301DEE548IMCMBX03MITREOR_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Does this conversation ne= ed to wait until the ietf meeting?

<= /p>
Given that many of the pa= rticipants will be at developer days in two weeks maybe some discussion cou= ld be held afterhours there?

<= /p>
This might allow for a mo= re mature draft to be discussed at the IETF meeting a few weeks later.=

<= /p>

Jon

<= /p>
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Jonathan O. Baker

G022 - IA Industry Collab= oration

The MITRE Corporation

Email: bakerj@mitre.org

<= /p>

From: sacm-bou= nces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of kathleen.moriarty@emc.com
Sent: Thursday, June 28, 2012 12:39 PM
To: karen@scarfonecybersecurity.com; sacm@ietf.org
Subject: Re: [sacm] IETF 84

Thanks for starting the t= hread, Adam and offering to help Karen!

<= /p>
A few of us have been wor= king to update the use case document that David Waltermire circulated. = ; We may need help here as I am not sure if we have content for each of the use cases yet. I provided content to update use case 5.<= o:p>

<= /p>
The hope was to review th= e use cases in a side meeting and start looking at a charter in support of = the defined use cases. From there, we can figure out what work is needed to support the use cases and charter. This would be u= sed to set the milestones.

<= /p>
Should we set a meeting f= or the Sunday again?

<= /p>
Thank you,

Kathleen

<= /p>

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Karen Scarfone
Sent: Thursday, June 28, 2012 12:22 PM
To: sacm@ietf.org
Subject: Re: [sacm] IETF 84

I've gotten out of the loop on this as well. I'm sti= ll available to edit any documents being produced by this effort.

Karen

On Thu, Jun 28, 2012 at 12:03 PM, Adam Montville <= ;amontville@tr= ipwire.com> wrote:

All:

I've been out of this loop for a while, unfortunately. Hopefully, the= re
is progress being made on the use cases and other efforts (I.e. content
repository) that were proposed a couple of months ago.

Can anyone tell me whether there is a scheduled meeting (side or
otherwise) for SACM during IETF 84? If so, do we have any idea when i= t
will be held?

Regards,

Adam

_______________________________________________
sacm mailing list
sacm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sacm

--
Karen Scarfone, Principal Consultant, Scarfone Cybersecurity
karen@= scarfonecybersecurity.com   (703)401-1018

--_000_6C1C15D8B5510B4B8FF132B10D38651301DEE548IMCMBX03MITREOR_-- From tonynad@microsoft.com Thu Jun 28 10:00:32 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA11321F854E for ; Thu, 28 Jun 2012 10:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.617 X-Spam-Level: X-Spam-Status: No, score=-0.617 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7m5cEQaSl6VY for ; Thu, 28 Jun 2012 10:00:32 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9B11B21F8540 for ; Thu, 28 Jun 2012 10:00:31 -0700 (PDT) Received: from mail8-db3-R.bigfish.com (10.3.81.251) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.23; Thu, 28 Jun 2012 16:58:44 +0000 Received: from mail8-db3 (localhost [127.0.0.1]) by mail8-db3-R.bigfish.com (Postfix) with ESMTP id D37454013B for ; Thu, 28 Jun 2012 16:58:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -35 X-BigFish: VS-35(zz98dI9371I9f17R148cI542Mzz1202h1082kzz1033IL8275bh8275dhz2fh2a8h683h839h944hd25hf0ah) Received-SPF: pass (mail8-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT002.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail8-db3 (localhost.localdomain [127.0.0.1]) by mail8-db3 (MessageSwitch) id 1340902722711567_16513; Thu, 28 Jun 2012 16:58:42 +0000 (UTC) Received: from DB3EHSMHS007.bigfish.com (unknown [10.3.81.252]) by mail8-db3.bigfish.com (Postfix) with ESMTP id A17F440004A for ; Thu, 28 Jun 2012 16:58:42 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS007.bigfish.com (10.3.87.107) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 28 Jun 2012 16:58:39 +0000 Received: from am1outboundpool.messaging.microsoft.com (157.54.51.112) by mail.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.2.309.3; Thu, 28 Jun 2012 17:00:18 +0000 Received: from mail46-am1-R.bigfish.com (10.3.201.254) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.23; Thu, 28 Jun 2012 16:57:28 +0000 Received: from mail46-am1 (localhost [127.0.0.1]) by mail46-am1-R.bigfish.com (Postfix) with ESMTP id E3F4D4A0248 for ; Thu, 28 Jun 2012 16:57:27 +0000 (UTC) Received: from mail46-am1 (localhost.localdomain [127.0.0.1]) by mail46-am1 (MessageSwitch) id 1340902645907270_19911; Thu, 28 Jun 2012 16:57:25 +0000 (UTC) Received: from AM1EHSMHS015.bigfish.com (unknown [10.3.201.246]) by mail46-am1.bigfish.com (Postfix) with ESMTP id D1A154E0049; Thu, 28 Jun 2012 16:57:25 +0000 (UTC) Received: from BL2PRD0310HT002.namprd03.prod.outlook.com (157.56.240.21) by AM1EHSMHS015.bigfish.com (10.3.207.153) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 28 Jun 2012 16:57:25 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.10.205]) by BL2PRD0310HT002.namprd03.prod.outlook.com ([10.255.97.37]) with mapi id 14.16.0164.004; Thu, 28 Jun 2012 16:59:04 +0000 From: Anthony Nadalin To: Adam Montville , "Kent_Landfield@McAfee.com" , "kathleen.moriarty@emc.com" , "karen@scarfonecybersecurity.com" , "sacm@ietf.org" Thread-Topic: [sacm] IETF 84 Thread-Index: AQHNVUeKYUpL4z7vTUubxQ1VahOvyJcP6b6AgAAExgCAAALAgIAAAP+AgAABzMA= Date: Thu, 28 Jun 2012 16:59:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.174.57] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT002.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TRIPWIRE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%MCAFEE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%EMC.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%SCARFONECYBERSECURITY.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC102.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC102.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Subject: Re: [sacm] IETF 84 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol $SCAP$." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 17:00:32 -0000 +1 -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Ada= m Montville Sent: Thursday, June 28, 2012 9:53 AM To: Kent_Landfield@McAfee.com; kathleen.moriarty@emc.com; karen@scarfonecyb= ersecurity.com; sacm@ietf.org Subject: Re: [sacm] IETF 84 I would also prefer a day other than Sunday, though I can make that work if= needed. Adam From: kent_landfield > Date: Thursday, June 28, 2012 9:48 AM To: "kathleen.moriarty@emc.com" >, "karen@scarfonecybers= ecurity.com" >, "sacm@ietf.org" > Subject: Re: [sacm] IETF 84 Personally I'd rather not do Sunday if we can. It worked but we had a coupl= e people that wanted to be there that did not arrive until after the meetin= g and could not listen in as they were in transit at the time. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Kathleen Moriarty > To: "karen@scarfonecybersecurity.com" = >, "sacm@ietf.org" > Subject: Re: [sacm] IETF 84 Thanks for starting the thread, Adam and offering to help Karen! A few of us have been working to update the use case document that David Wa= ltermire circulated. We may need help here as I am not sure if we have con= tent for each of the use cases yet. I provided content to update use case = 5. The hope was to review the use cases in a side meeting and start looking at= a charter in support of the defined use cases. From there, we can figure = out what work is needed to support the use cases and charter. This would b= e used to set the milestones. Should we set a meeting for the Sunday again? Thank you, Kathleen From:sacm-bounces@ietf.org [mailto:sacm-bounc= es@ietf.org] On Behalf Of Karen Scarfone Sent: Thursday, June 28, 2012 12:22 PM To: sacm@ietf.org Subject: Re: [sacm] IETF 84 I've gotten out of the loop on this as well. I'm still available to edit an= y documents being produced by this effort. Karen On Thu, Jun 28, 2012 at 12:03 PM, Adam Montville > wrote: All: I've been out of this loop for a while, unfortunately. Hopefully, there is= progress being made on the use cases and other efforts (I.e. content repository) that were proposed a couple of months ago. Can anyone tell me whether there is a scheduled meeting (side or otherwise) for SACM during IETF 84? If so, do we have any idea when it wil= l be held? Regards, Adam _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm -- Karen Scarfone, Principal Consultant, Scarfone Cybersecurity karen@scarfonecybersecurity.com (= 703)401-1018 _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From kathleen.moriarty@emc.com Thu Jun 28 10:10:28 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCCFE21F8555 for ; Thu, 28 Jun 2012 10:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyxumJAl2QCR for ; Thu, 28 Jun 2012 10:10:26 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id C400C21F853E for ; Thu, 28 Jun 2012 10:10:25 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5SHA3Pm009195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2012 13:10:16 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Thu, 28 Jun 2012 13:09:49 -0400 Received: from mxhub11.corp.emc.com (mxhub11.corp.emc.com [10.254.92.106]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5SH9mkf020529; Thu, 28 Jun 2012 13:09:48 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub11.corp.emc.com ([10.254.92.106]) with mapi; Thu, 28 Jun 2012 13:09:48 -0400 From: To: , , Date: Thu, 28 Jun 2012 13:09:47 -0400 Thread-Topic: [sacm] IETF 84 Thread-Index: AQHNVUeKYUpL4z7vTUubxQ1VahOvyJcQLMyAgAAExgD//8HKoIAAAc0A Message-ID: References: <6C1C15D8B5510B4B8FF132B10D38651301DEE548@IMCMBX03.MITRE.ORG> In-Reply-To: <6C1C15D8B5510B4B8FF132B10D38651301DEE548@IMCMBX03.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5063677821E3B4F81ACFB7905573F2403949B53MX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [sacm] IETF 84 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol $SCAP$." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 17:10:29 -0000 --_000_F5063677821E3B4F81ACFB7905573F2403949B53MX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, We need to set an agenda and plan for a meeting, so the discussion does nee= d to happen and is good to have on the list so that participation is not li= mited to those that can't attend developer days. We can of course discuss = the use case development at developer days, but need to have discussions on= the list for the broader community. We also have timelines to post -00 drafts and -01 prior to the IETF meeting= s adhering to the IETF meeting dates schedule. This gives attendees enough= time to review documents prior to the meeting. Thank you, Kathleen From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Bak= er, Jon Sent: Thursday, June 28, 2012 12:59 PM To: Moriarty, Kathleen; karen@scarfonecybersecurity.com; sacm@ietf.org Subject: Re: [sacm] IETF 84 Does this conversation need to wait until the ietf meeting? Given that many of the participants will be at developer days in two weeks = maybe some discussion could be held afterhours there? This might allow for a more mature draft to be discussed at the IETF meetin= g a few weeks later. Jon =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jonathan O. Baker G022 - IA Industry Collaboration The MITRE Corporation Email: bakerj@mitre.org From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of kat= hleen.moriarty@emc.com Sent: Thursday, June 28, 2012 12:39 PM To: karen@scarfonecybersecurity.com; sacm@ietf.org Subject: Re: [sacm] IETF 84 Thanks for starting the thread, Adam and offering to help Karen! A few of us have been working to update the use case document that David Wa= ltermire circulated. We may need help here as I am not sure if we have con= tent for each of the use cases yet. I provided content to update use case = 5. The hope was to review the use cases in a side meeting and start looking at= a charter in support of the defined use cases. From there, we can figure = out what work is needed to support the use cases and charter. This would b= e used to set the milestones. Should we set a meeting for the Sunday again? Thank you, Kathleen From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Karen Sca= rfone Sent: Thursday, June 28, 2012 12:22 PM To: sacm@ietf.org Subject: Re: [sacm] IETF 84 I've gotten out of the loop on this as well. I'm still available to edit an= y documents being produced by this effort. Karen On Thu, Jun 28, 2012 at 12:03 PM, Adam Montville > wrote: All: I've been out of this loop for a while, unfortunately. Hopefully, there is progress being made on the use cases and other efforts (I.e. content repository) that were proposed a couple of months ago. Can anyone tell me whether there is a scheduled meeting (side or otherwise) for SACM during IETF 84? If so, do we have any idea when it will be held? Regards, Adam _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm -- Karen Scarfone, Principal Consultant, Scarfone Cybersecurity karen@scarfonecybersecurity.com (= 703)401-1018 --_000_F5063677821E3B4F81ACFB7905573F2403949B53MX15Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Jon,

We need to set an agenda and plan for a meetin= g, so the discussion does need to happen and is good to have on the list so= that participation is not limited to those that can’t attend develop= er days. We can of course discuss the use case development at develop= er days, but need to have discussions on the list for the broader community= .
=
We also have timelines to post -00 d= rafts and -01 prior to the IETF meetings adhering to the IETF meeting dates= schedule. This gives attendees enough time to review documents prior= to the meeting.
&nbs= p;
Thank you,=
Kathleen

Fr= om: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of= Baker, Jon
Sent: Thursday, June 28, 2012 12:59 PM
To:<= /b> Moriarty, Kathleen; karen@scarfonecybersecurity.com; sacm@ietf.org
<= b>Subject: Re: [sacm] IETF 84

Does this con= versation need to wait until the ietf meeting?

Given that many of the participants will be at developer days in two week= s maybe some discussion could be held afterhours there? <= /p>

This might allow for a more mature draft to be discussed at the= IETF meeting a few weeks later.
=
Jon

<= p class=3DMsoNormal>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
Jonathan O. Bake= r
G022 - IA Industry Colla= boration
The MITRE Corpora= tion
Email: ba= kerj@mitre.org
<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>
From= : sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of <= /b>kathleen.moriarty@emc.com
Sent: Thursday, June 28, 2012 12:39 = PM
To: karen@scarfonecybersecurity.com; sacm@ietf.org
Subje= ct: Re: [sacm] IETF 84

Thanks for starting = the thread, Adam and offering to help Karen!

A few of us have been working to update the use case document that David W= altermire circulated. We may need help here as I am not sure if we ha= ve content for each of the use cases yet. I provided content to updat= e use case 5.
<= /o:p>
The hope was to review the use = cases in a side meeting and start looking at a charter in support of the de= fined use cases. From there, we can figure out what work is needed to= support the use cases and charter. This would be used to set the mil= estones.
=
Should we set a meeting for the Sund= ay again?

Thank you,
Kathleen

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] = On Behalf Of Karen Scarfone
Sent: Thursday, June 28, 2012 12:= 22 PM
To: sacm@ietf.org
<= b>Subject: Re: [sacm] IETF 84

I've gotten out of the loo= p on this as well. I'm still available to edit any documents being produced= by this effort.
<= /p>

Karen
On Thu, Jun 28, 2012 at 12:03 PM, Adam Montville <amontville@tripwire.c= om> wrote:
All:

I've been = out of this loop for a while, unfortunately. Hopefully, there
is p= rogress being made on the use cases and other efforts (I.e. content
repo= sitory) that were proposed a couple of months ago.

Can anyone tell m= e whether there is a scheduled meeting (side or
otherwise) for SACM duri= ng IETF 84? If so, do we have any idea when it
will be held?
Regards,

Adam

_________________________________________= ______
sacm mailing list
sacm@ietf.o= rg
https://www.ietf.org/mailman/listinfo/sacm
=

--
Karen Scarfone, Principal Consultant, Scarfone Cybersecur= ity
karen@scarfonecybersecurity.com   (703)401-1018
= --_000_F5063677821E3B4F81ACFB7905573F2403949B53MX15Acorpemccom_-- From Kent_Landfield@mcafee.com Thu Jun 28 10:11:48 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F66921F8555 for ; Thu, 28 Jun 2012 10:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qn9XDnYJW9F5 for ; Thu, 28 Jun 2012 10:11:47 -0700 (PDT) Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by ietfa.amsl.com (Postfix) with ESMTP id 4A10E21F853E for ; Thu, 28 Jun 2012 10:11:47 -0700 (PDT) Received: from DALEXHT1.corp.nai.org (unknown [10.64.5.51]) by dalsmrelay2.nai.com with smtp id 04da_05b5_aba84bfe_8c0b_4dfc_bc82_93a5f56cf9b8; Thu, 28 Jun 2012 12:11:37 -0500 Received: from AMERDALEXMB1.corp.nai.org ([fe80::b534:4a0d:1289:2d2d]) by DALEXHT1.corp.nai.org ([::1]) with mapi; Thu, 28 Jun 2012 12:07:47 -0500 From: To: , , , Date: Thu, 28 Jun 2012 12:08:35 -0500 Thread-Topic: [sacm] IETF 84 Thread-Index: Ac1VUIn35sRIjOsgTjWDcvLkwiK9Cw== Message-ID: In-Reply-To: <6C1C15D8B5510B4B8FF132B10D38651301DEE548@IMCMBX03.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC11F87A36431kentlandfieldmcafeecom_" MIME-Version: 1.0 Subject: Re: [sacm] IETF 84 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol $SCAP$." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 17:11:48 -0000 --_000_CC11F87A36431kentlandfieldmcafeecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Absolutely not! We can be having it right now. I agree there is no need t= o wait for meetings to have these discussions. Quite the contrary, we shoul= d be having these discussions on the list. Since a large section of the com= munity participants will be at Dev Days we can also use that as a way to ma= ture the discussion and documented use cases. And from my perspective, I see the use case I-D covering more that what wil= l be a single proposed working group charter might cover. It also discusse= s items that are currently being worked in other working groups. We initia= lly thought the use case document could drive the charter discussion but th= at seems to be artificially delaying the discussion from starting. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , Jon > To: Kathleen Moriarty >, "karen@scarfonecybersecurity.com" >, "sacm@ietf.org" > Subject: Re: [sacm] IETF 84 Does this conversation need to wait until the ietf meeting? Given that many of the participants will be at developer days in two weeks = maybe some discussion could be held afterhours there? This might allow for a more mature draft to be discussed at the IETF meetin= g a few weeks later. Jon =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jonathan O. Baker G022 - IA Industry Collaboration The MITRE Corporation Email: bakerj@mitre.org From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of kathleen.moriarty@emc.com Sent: Thursday, June 28, 2012 12:39 PM To: karen@scarfonecybersecurity.com= ; sacm@ietf.org Subject: Re: [sacm] IETF 84 Thanks for starting the thread, Adam and offering to help Karen! A few of us have been working to update the use case document that David Wa= ltermire circulated. We may need help here as I am not sure if we have con= tent for each of the use cases yet. I provided content to update use case = 5. The hope was to review the use cases in a side meeting and start looking at= a charter in support of the defined use cases. From there, we can figure = out what work is needed to support the use cases and charter. This would b= e used to set the milestones. Should we set a meeting for the Sunday again? Thank you, Kathleen From:sacm-bounces@ietf.org [mailto:sacm-bounc= es@ietf.org] On Behalf Of Karen Scar= fone Sent: Thursday, June 28, 2012 12:22 PM To: sacm@ietf.org Subject: Re: [sacm] IETF 84 I've gotten out of the loop on this as well. I'm still available to edit an= y documents being produced by this effort. Karen On Thu, Jun 28, 2012 at 12:03 PM, Adam Montville > wrote: All: I've been out of this loop for a while, unfortunately. Hopefully, there is progress being made on the use cases and other efforts (I.e. content repository) that were proposed a couple of months ago. Can anyone tell me whether there is a scheduled meeting (side or otherwise) for SACM during IETF 84? If so, do we have any idea when it will be held? Regards, Adam _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm -- Karen Scarfone, Principal Consultant, Scarfone Cybersecurity karen@scarfonecybersecurity.com (= 703)401-1018 --_000_CC11F87A36431kentlandfieldmcafeecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Abso= lutely not! We can be having it right now. I agree there is no = need to wait for meetings to have these discussions. Quite the contrary, we= should be having these discussions on the list. Since a large section of t= he community participants will be at Dev Days we can also use that as a way= to mature the discussion and documented use cases.

And from my perspective, I see the use case I-D covering more that= what will be a single proposed working group charter might cover. It= also discusses items that are currently being worked in other working grou= ps. We initially thought the use case document could drive the charte= r discussion but that seems to be artificially delaying the discussion from= starting.

Kent Landfield

McAfee | An Intel Company<= /strong>Direct: = +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com

From: <Baker>, Jon <bakerj@mitr= e.org>
To: Kathleen Mori= arty <kathleen.moriarty@emc= .com>, "karen@sca= rfonecybersecurity.com" <karen@scarfonecybersecurity.com>, "sacm@ietf.org" <sacm@ietf.o= rg>
Subject: Re: [sacm] = IETF 84

Does this conversation need to wait until the ietf meeting?

Given that many of the part= icipants will be at developer days in two weeks maybe some discussion could= be held afterhours there?
<= /o:p>
This might allow f= or a more mature draft to be discussed at the IETF meeting a few weeks late= r.
= ;
Jon

=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Jonathan O. Baker
G022 - IA Industry Collaboration
The MITRE Corporation
Email: bakerj@mitre.org

From: = sacm-bounces@ietf.org [mailto:= sacm-bounces@ietf.org] On Behalf Of kathleen.m= oriarty@emc.com
Sent: Thursday, June 28, 2012 12:39 PM
= To: karen@scarfonecy= bersecurity.com; sacm@ietf.org
= Subject: Re: [sacm] IETF 84

A few of us have been work= ing to update the use case document that David Waltermire circulated. = We may need help here as I am not sure if we have content for each of the use cases yet. I provided content to update use case 5.<= o:p>

The hope was to rev= iew the use cases in a side meeting and start looking at a charter in suppo= rt of the defined use cases. From there, we can figure out what work is needed to support the use cases and charter. This would be u= sed to set the milestones.

Should we set a meeting for the Sunday again?
=

Thank you,
Kathleen

From:sacm-bounces@iet= f.org [mailto:sacm-bounces@ietf.org] On Behalf Of Karen Scarfone
Sent: Thursday, June 28, 2012 12:22 PM
To: sacm@ietf.org
Subject: Re: [sacm] IETF 84

I've gotten out of the loop on this as well. I'm still avai= lable to edit any documents being produced by this effort.

Karen
On Thu, Ju= n 28, 2012 at 12:03 PM, Adam Montville <amontville@tripwire.com> wrote:
All:

I've been out of this loop for a while, unfortunately. Hopefully, the= re
is progress being made on the use cases and other efforts (I.e. content
= repository) that were proposed a couple of months ago.

Can anyone tell me whether there is a scheduled meeting (side or
otherwise) for SACM during IETF 84? If so, do we have any idea when i= t
will be held?

Regards,

Adam

_______________________________________________
sacm mailing list
sacm@ietf.org
= ht= tps://www.ietf.org/mailman/listinfo/sacm

--
Karen Scarfone, Principal Consultant, Scarfone Cybersecurity
karen@scarfonecyb= ersecurity.com   (703)401-1018
--_000_CC11F87A36431kentlandfieldmcafeecom_-- From kathleen.moriarty@emc.com Fri Jun 29 09:07:45 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4B421F857D for ; Fri, 29 Jun 2012 09:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZ1NjcE4mBzP for ; Fri, 29 Jun 2012 09:07:44 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id AF9E021F8513 for ; Fri, 29 Jun 2012 09:07:43 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5TG7fve023100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2012 12:07:42 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Fri, 29 Jun 2012 12:07:34 -0400 Received: from mxhub33.corp.emc.com (mxhub33.corp.emc.com [10.254.93.81]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5TG7YBZ022530; Fri, 29 Jun 2012 12:07:34 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub33.corp.emc.com ([::1]) with mapi; Fri, 29 Jun 2012 12:07:33 -0400 From: To: , , , Date: Fri, 29 Jun 2012 12:07:32 -0400 Thread-Topic: [sacm] IETF 84 Thread-Index: Ac1VUIn35sRIjOsgTjWDcvLkwiK9CwAwFQeQ Message-ID: References: <6C1C15D8B5510B4B8FF132B10D38651301DEE548@IMCMBX03.MITRE.ORG> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5063677821E3B4F81ACFB7905573F2403AA99D4MX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [sacm] IETF 84 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol $SCAP$." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 16:07:45 -0000 --_000_F5063677821E3B4F81ACFB7905573F2403AA99D4MX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, The agenda was released for IETF 84 and is at the following link: https://datatracker.ietf.org/meeting/84/agenda.txt Do people have an opinion as to when they would like the meeting to take pl= ace (cannot conflict with other IETF meeting times or plenary sessions)? I= f it helps, MILE is scheduled for Tuesday afternoon right now. NEA is not = scheduled to meet. We will need to put in the request soon for planning purposes for both the = IETF and attendees. Thank you, Kathleen From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Ken= t_Landfield@McAfee.com Sent: Thursday, June 28, 2012 1:09 PM To: bakerj@mitre.org; Moriarty, Kathleen; karen@scarfonecybersecurity.com; = sacm@ietf.org Subject: Re: [sacm] IETF 84 Absolutely not! We can be having it right now. I agree there is no need t= o wait for meetings to have these discussions. Quite the contrary, we shoul= d be having these discussions on the list. Since a large section of the com= munity participants will be at Dev Days we can also use that as a way to ma= ture the discussion and documented use cases. And from my perspective, I see the use case I-D covering more that what wil= l be a single proposed working group charter might cover. It also discusse= s items that are currently being worked in other working groups. We initia= lly thought the use case document could drive the charter discussion but th= at seems to be artificially delaying the discussion from starting. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , Jon > To: Kathleen Moriarty >, "karen@scarfonecybersecurity.com" >, "sacm@ietf.org" > Subject: Re: [sacm] IETF 84 Does this conversation need to wait until the ietf meeting? Given that many of the participants will be at developer days in two weeks = maybe some discussion could be held afterhours there? This might allow for a more mature draft to be discussed at the IETF meetin= g a few weeks later. Jon =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jonathan O. Baker G022 - IA Industry Collaboration The MITRE Corporation Email: bakerj@mitre.org From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of kathleen.moriarty@emc.com Sent: Thursday, June 28, 2012 12:39 PM To: karen@scarfonecybersecurity.com= ; sacm@ietf.org Subject: Re: [sacm] IETF 84 Thanks for starting the thread, Adam and offering to help Karen! A few of us have been working to update the use case document that David Wa= ltermire circulated. We may need help here as I am not sure if we have con= tent for each of the use cases yet. I provided content to update use case = 5. The hope was to review the use cases in a side meeting and start looking at= a charter in support of the defined use cases. From there, we can figure = out what work is needed to support the use cases and charter. This would b= e used to set the milestones. Should we set a meeting for the Sunday again? Thank you, Kathleen From:sacm-bounces@ietf.org [mailto:sacm-bounc= es@ietf.org] On Behalf Of Karen Scar= fone Sent: Thursday, June 28, 2012 12:22 PM To: sacm@ietf.org Subject: Re: [sacm] IETF 84 I've gotten out of the loop on this as well. I'm still available to edit an= y documents being produced by this effort. Karen On Thu, Jun 28, 2012 at 12:03 PM, Adam Montville > wrote: All: I've been out of this loop for a while, unfortunately. Hopefully, there is progress being made on the use cases and other efforts (I.e. content repository) that were proposed a couple of months ago. Can anyone tell me whether there is a scheduled meeting (side or otherwise) for SACM during IETF 84? If so, do we have any idea when it will be held? Regards, Adam _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm -- Karen Scarfone, Principal Consultant, Scarfone Cybersecurity karen@scarfonecybersecurity.com (= 703)401-1018 --_000_F5063677821E3B4F81ACFB7905573F2403AA99D4MX15Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello,
&nb= sp;
The agenda was released for= IETF 84 and is at the following link:
https://datatracker.ietf.org/meeting/84/agenda.txt

Do people have an opinion as to when they would like the meeting= to take place (cannot conflict with other IETF meeting times or plenary se= ssions)? If it helps, MILE is scheduled for Tuesday afternoon right n= ow. NEA is not scheduled to meet.

We w= ill need to put in the request soon for planning purposes for both the IETF= and attendees.
= ;
Thank you,<= /p>
Kathleen

Fro= m: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of = Kent_Landfield@McAfee.com
Sent: Thursday, June 28, 2012 1:09 = PM
To: bakerj@mitre.org; Moriarty, Kathleen; karen@scarfonecybers= ecurity.com; sacm@ietf.org
Subject: Re: [sacm] IETF 84=

=
Absolutely not! = ;We can be having it right now. I agree there is no need to wait for = meetings to have these discussions. Quite the contrary, we should be having= these discussions on the list. Since a large section of the community part= icipants will be at Dev Days we can also use that as a way to mature the di= scussion and documented use cases.
<= p class=3DMsoNormal>
And from my pe= rspective, I see the use case I-D covering more that what will be a single = proposed working group charter might cover. It also discusses items t= hat are currently being worked in other working groups. We initially = thought the use case document could drive the charter discussion but that s= eems to be artificially delaying the discussion from starting. <= /o:p>

<= span style=3D'font-size:9.0pt;font-family:"Arial","sans-serif";color:#606A7= 1'>Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com=
&nb= sp;
From: <Baker>, Jon <baker= j@mitre.org>
To: Kathleen Moriarty <kathleen.moriarty@emc.com>, "karen@scarfonecybersecurity.com= " <karen@sca= rfonecybersecurity.com>, "sacm= @ietf.org" <sacm@ietf.org&= gt;
Subject: Re: [sacm] IETF 84
<= p class=3DMsoNormal>
Does this = conversation need to wait until the ietf meeting?

= Given that many of the participants will be at developer days in two weeks = maybe some discussion could be held afterhours there?

This might allow for a more mature draft to be discussed at the IETF m= eeting a few weeks later.

Jon
&nbs= p;
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Jonathan O. Baker<= /p>
G022 - IA Industry Collaboration
Th= e MITRE Corporation
Email: bakerj@mitre.org=
=
From: <= a href=3D"mailto:sacm-bounces@ietf.org">sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On B= ehalf Of kathleen.moriarty= @emc.com
Sent: Thursday, June 28, 2012 12:39 PM
To:= karen@scarfonecybersecu= rity.com; sacm@ietf.org
Subj= ect: Re: [sacm] IETF 84
= ;
Thanks for starting the = thread, Adam and offering to help Karen!=

A few of= us have been working to update the use case document that David Waltermire= circulated. We may need help here as I am not sure if we have conten= t for each of the use cases yet. I provided content to update use cas= e 5.

The hope was to review the use cases in a sid= e meeting and start looking at a charter in support of the defined use case= s. From there, we can figure out what work is needed to support the u= se cases and charter. This would be used to set the milestones.

Should we set a meeting for the Sunday again?
=
Thank you,
Kathleen

= From:sacm-bounc= es@ietf.org [mailto:s= acm-bounces@ietf.org] On Behalf Of Karen Scarfone
Sent: Thursday, June 28, 2012 12:22 PM
To: sacm@ietf.org
Subject: Re: [sacm] IETF 84

I've gotten out of the loop on this as well. I'm = still available to edit any documents being produced by this effort.
=

Karen<= /p>
On Thu, Jun 28, 20= 12 at 12:03 PM, Adam Montville <amontville@tripwire.com> wrote:
All:

I've bee= n out of this loop for a while, unfortunately. Hopefully, there
is= progress being made on the use cases and other efforts (I.e. content
re= pository) that were proposed a couple of months ago.

Can anyone tell= me whether there is a scheduled meeting (side or
otherwise) for SACM du= ring IETF 84? If so, do we have any idea when it
will be held?
=
Regards,

Adam

_______________________________________= ________
sacm mailing list
sacm@ietf= .org
https://www.ietf.org/mailman/listinfo/sacm

--
Karen Scarfone, Princ= ipal Consultant, Scarfone Cybersecurity
karen@scarfonecybersecurity.com&nb= sp; (703)401-1018
= --_000_F5063677821E3B4F81ACFB7905573F2403AA99D4MX15Acorpemccom_-- From amontville@tripwire.com Fri Jun 29 09:26:51 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67FC721F877A for ; Fri, 29 Jun 2012 09:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.349 X-Spam-Level: X-Spam-Status: No, score=-4.349 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 659divJWem1i for ; Fri, 29 Jun 2012 09:26:50 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id 45FDA21F8781 for ; Fri, 29 Jun 2012 09:26:50 -0700 (PDT) Received: from mail57-va3-R.bigfish.com (10.7.14.246) by VA3EHSOBE011.bigfish.com (10.7.40.61) with Microsoft SMTP Server id 14.1.225.23; Fri, 29 Jun 2012 16:25:00 +0000 Received: from mail57-va3 (localhost [127.0.0.1]) by mail57-va3-R.bigfish.com (Postfix) with ESMTP id 369CD2C0478; Fri, 29 Jun 2012 16:25:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.216; KIP:(null); UIP:(null); IPV:NLI; H:PDXED01.tripwire.com; RD:174-47-84-216.static.twtelecom.net; EFVD:NLI X-SpamScore: -34 X-BigFish: VPS-34(zz98dI9371I9f17R148cI62a3Izz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h944he5bhf0ah) Received: from mail57-va3 (localhost.localdomain [127.0.0.1]) by mail57-va3 (MessageSwitch) id 1340987097934551_12066; Fri, 29 Jun 2012 16:24:57 +0000 (UTC) Received: from VA3EHSMHS011.bigfish.com (unknown [10.7.14.253]) by mail57-va3.bigfish.com (Postfix) with ESMTP id D5F7A460053; Fri, 29 Jun 2012 16:24:57 +0000 (UTC) Received: from PDXED01.tripwire.com (174.47.84.216) by VA3EHSMHS011.bigfish.com (10.7.99.21) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 29 Jun 2012 16:24:57 +0000 Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 29 Jun 2012 09:27:35 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0355.002; Fri, 29 Jun 2012 09:26:45 -0700 From: Adam Montville To: "kathleen.moriarty@emc.com" , "Kent_Landfield@McAfee.com" , "bakerj@mitre.org" , "karen@scarfonecybersecurity.com" , "sacm@ietf.org" Thread-Topic: [sacm] IETF 84 Thread-Index: AQHNVUeKYUpL4z7vTUubxQ1VahOvyJcQXxeAgAAExgCAAAWmgIAAApSAgAGBRgD//5ACAA== Date: Fri, 29 Jun 2012 16:26:44 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [172.16.97.55] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-ID: <45E095E672FC5F4DBFB40F32A55B65A6@tripwire.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: tripwire.com Subject: Re: [sacm] IETF 84 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol $SCAP$." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 16:26:51 -0000 I'd suggest Thursday evening. Alternatively, the mornings of Monday and Tu= esday are light for the security area, but we might end up interfering with= ops if we go that route, and if I'm not mistaken we'd like to potentially = have some ops people attend. Adam From: "kathleen.moriarty@emc.com" > Date: Friday, June 29, 2012 9:07 AM To: kent_landfield >, Jon Baker >, "karen@scarfo= necybersecurity.com" >, "sacm@ietf.org= " > Subject: Re: [sacm] IETF 84 Hello, The agenda was released for IETF 84 and is at the following link: https://datatracker.ietf.org/meeting/84/agenda.txt Do people have an opinion as to when they would like the meeting to take pl= ace (cannot conflict with other IETF meeting times or plenary sessions)? I= f it helps, MILE is scheduled for Tuesday afternoon right now. NEA is not = scheduled to meet. We will need to put in the request soon for planning purposes for both the = IETF and attendees. Thank you, Kathleen From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Kent_Landfield@McAfee.com Sent: Thursday, June 28, 2012 1:09 PM To: bakerj@mitre.org; Moriarty, Kathleen; karen@sc= arfonecybersecurity.com; sacm@ietf.= org Subject: Re: [sacm] IETF 84 Absolutely not! We can be having it right now. I agree there is no need t= o wait for meetings to have these discussions. Quite the contrary, we shoul= d be having these discussions on the list. Since a large section of the com= munity participants will be at Dev Days we can also use that as a way to ma= ture the discussion and documented use cases. And from my perspective, I see the use case I-D covering more that what wil= l be a single proposed working group charter might cover. It also discusse= s items that are currently being worked in other working groups. We initia= lly thought the use case document could drive the charter discussion but th= at seems to be artificially delaying the discussion from starting. Kent Landfield McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: , Jon > To: Kathleen Moriarty >, "karen@scarfonecybersecurity.com" >, "sacm@ietf.org" > Subject: Re: [sacm] IETF 84 Does this conversation need to wait until the ietf meeting? Given that many of the participants will be at developer days in two weeks = maybe some discussion could be held afterhours there? This might allow for a more mature draft to be discussed at the IETF meetin= g a few weeks later. Jon =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jonathan O. Baker G022 - IA Industry Collaboration The MITRE Corporation Email: bakerj@mitre.org From:sacm-bounces@ietf.org [mailto:sacm-bounc= es@ietf.org] On Behalf Of kathleen.moriarty@emc.com Sent: Thursday, June 28, 2012 12:39 PM To: karen@scarfonecybersecurity.com= ; sacm@ietf.org Subject: Re: [sacm] IETF 84 Thanks for starting the thread, Adam and offering to help Karen! A few of us have been working to update the use case document that David Wa= ltermire circulated. We may need help here as I am not sure if we have con= tent for each of the use cases yet. I provided content to update use case = 5. The hope was to review the use cases in a side meeting and start looking at= a charter in support of the defined use cases. From there, we can figure = out what work is needed to support the use cases and charter. This would b= e used to set the milestones. Should we set a meeting for the Sunday again? Thank you, Kathleen From:sacm-bounces@ietf.org[mailto:sacm-bounce= s@ietf.org]On Behalf Of Karen Scarfo= ne Sent: Thursday, June 28, 2012 12:22 PM To: sacm@ietf.org Subject: Re: [sacm] IETF 84 I've gotten out of the loop on this as well. I'm still available to edit an= y documents being produced by this effort. Karen On Thu, Jun 28, 2012 at 12:03 PM, Adam Montville > wrote: All: I've been out of this loop for a while, unfortunately. Hopefully, there is progress being made on the use cases and other efforts (I.e. content repository) that were proposed a couple of months ago. Can anyone tell me whether there is a scheduled meeting (side or otherwise) for SACM during IETF 84? If so, do we have any idea when it will be held? Regards, Adam _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm -- Karen Scarfone, Principal Consultant, Scarfone Cybersecurity karen@scarfonecybersecurity.com (= 703)401-1018 From athiasjerome@gmail.com Sat Jun 30 04:46:38 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D843D21F861A for ; Sat, 30 Jun 2012 04:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfcrs8H0Oz-z for ; Sat, 30 Jun 2012 04:46:38 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2A621F847C for ; Sat, 30 Jun 2012 04:46:37 -0700 (PDT) Received: by wibhq12 with SMTP id hq12so1564390wib.1 for ; Sat, 30 Jun 2012 04:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=otIwA/rxHJduY1E9gOVKJynPgrvN0/T2ajNj/eYNfVY=; b=U9SuWPvC/rTLpgsFVV2cV93Zv/rwK1Kw9oK5Z72c4wkgCxdpczknntltKwDoIieO/E neU9fEXIEBopGhkh2i6PZtu3z51ZuQmnTITb13Qj0oS8TUIdn/fqI3BDYqX1tJEPvR4w hban5AGHnVqgYKY8Jq5T9lSlxSq+Xup17eyn8TkaALDalH4+vivJU3w2R7h+4fjsn+MP Isf3WoxJUw0tXIgwo5pUPIHOcLOxsJgBz7jkLyt78XSJ9kzxXAGhDkSSoE7r2lj1dQpr TiLHBxtuWrz0jiXxf+ycJWi7WwYxCWDikk1bz4b8Bqgc5tbpyUGbm/ansUxoEPeYe16A I8Xg== MIME-Version: 1.0 Received: by 10.180.84.169 with SMTP id a9mr4446499wiz.8.1341056797596; Sat, 30 Jun 2012 04:46:37 -0700 (PDT) Received: by 10.194.54.7 with HTTP; Sat, 30 Jun 2012 04:46:37 -0700 (PDT) In-Reply-To: References: Date: Sat, 30 Jun 2012 13:46:37 +0200 Message-ID: From: Jerome Athias To: Adam Montville Content-Type: text/plain; charset=ISO-8859-1 Cc: "sacm@ietf.org" , "kathleen.moriarty@emc.com" , "Kent_Landfield@McAfee.com" , "bakerj@mitre.org" , "karen@scarfonecybersecurity.com" Subject: Re: [sacm] IETF 84 X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol $SCAP$." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 11:46:39 -0000 Hi, sorry I was out of the list due to a move and new email box. Maybe it is quite off topic, but I would like to know if some of you were at the latest MITRE's BIG DATA meeting? and if any of the presentations/papers are available? Thanks And I'm still interested to contribute to this list, help and review new drafts... Regards Jerome