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

From: [email-masked]
Date: Tue, 05 Jun 2012 09:04:02 -0500 (CDT)

I think that the hub idea may be needed at the beginning.  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 to reduce/share the burden.  The rotated management approach may give the participants a better feel for what works in the best interest of standardization and all particpating parties.

David Oliva

On 05/21/12, Waltermire, David A.<[email-masked]> wrote:

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

Any other thoughts?

Sincerely,
Dave

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Monday, May 21, 2012 1:18 PM
To: Waltermire, David A.; [email-masked]
Cc: SCAP-DEV; [email-masked]
Subject: RE: [sacm] [scap-dev] Request for participants - Content Repository Specification Development

It would be possible for centralized star, with reciprocal subscriptions.
Sources publish, and central devise broadcasts 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 see data needing to be transferred.
And whether an intra-poll delay is acceptable or not.

Mike

-----Original Message-----
From: Waltermire, David A. [mailto:[email-masked]]
Sent: Monday, May 21, 2012 1:09 PM
To: Michael Hammer; [email-masked]
Cc: SCAP-DEV; [email-masked]
Subject: RE: [sacm] [scap-dev] Request for participants - Content Repository
Specification Development

That is also an option. It could be supported in addition to a polling
method also. The challenge with pub-sub is that content 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 the 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:[email-masked]]
Sent: Monday, May 21, 2012 12:59 PM
To: Waltermire, David A.; [email-masked]
Cc: SCAP-DEV; [email-masked]
Subject: RE: [sacm] [scap-dev] Request for participants - Content Repository
Specification Development

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

Polling seems like it could get chatty, and raises the question of how
often.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Waltermire, David A.
Sent: Monday, May 21, 2012 10:42 AM
To: Gunnar Engelbach
Cc: SCAP-DEV; [email-masked]
Subject: Re: [sacm] [scap-dev] Request for participants - Content Repository
Specification Development

Comments inline marked [DAW].

Sincerely,
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Gunnar Engelbach
Sent: Friday, May 18, 2012 1:04 PM
Cc: SCAP-DEV; [email-masked]
Subject: Re: [sacm] [scap-dev] Request for participants - Content Repository
Specification Development

Dave,

It sounds like you are trying to solve two separate problems here.

The first is the ability to retrieve content from a repository, the second
is the ability to locate repositories.

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

[DAW: We would be introducing significant complexity into the client if we
separate these concerns. By mirroring the DNS approach for repository
federation, we can keep things simple on the client side. In my view, both
of these operations would be handled by the local content repository
associated with the client. Just like in 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 content 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 agent is ordered by the scanning
manager to perform a scan on a repeating interval 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 third party vendor's content repository.
The agent has been preconfigured to point to the local content repository to
which it sends a request to for the content. The local repository looks up
the namespace associated with 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, and 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: What 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
repository you first have to know something about the repository -- the
publisher's namespace URI from your example.

In my experience discovery is more likely to be based on search
criteria: affected platform, guidance source, supported languages, content
formats, regulation applicability (SOX, 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. Meaning that the organization performing the scan pre-selected
content from 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
then provide persistent pointers to the location of the content. We
probably need something like this too, but that is a concept that more than
likely 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 matters
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 configurations based
on content they have pre-selected and these configurations would then get
propagated to the individual scanners. The pre-selection could be the
result of querying a list of authoritative and trusted repositories. This
usage pattern also applies to single host and agentless approaches.]

--gun

On 5/18/2012 8:42 AM, Waltermire, David A. wrote:
> My comments marked with [DAW2].
>
> Sincerely,
> Dave
>
>
> -----Original Message-----
> From: Chandrashekhar B [mailto:[email-masked]]
> Sent: Friday, May 18, 2012 1:50 AM
> To: Waltermire, David A.; 'Kurt Seifried'
> Cc: [email-masked]; SCAP-DEV
> Subject: RE: [sacm] [scap-dev] Request for participants - Content
> Repository Specification Development
>
> My comments marked [CHA]
>
> Chandra.
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of
Waltermire, David A.
> Sent: Friday, May 18, 2012 8:02 AM
> To: Kurt Seifried
> Cc: [email-masked]
> Subject: Re: [sacm] [scap-dev] Request for participants - Content
> Repository Specification Development
>
> Comments inline marked [DAW].
>
> Sincerely,
> Dave
>
>
> -----Original Message-----
> From: Kurt Seifried [mailto:[email-masked]]
> Sent: Thursday, May 17, 2012 10:18 PM
> To: Waltermire, David A.
> Cc: [email-masked]
> Subject: Re: [scap-dev] [sacm] Request for participants - Content
> Repository Specification Development
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Note: all opinions/comments are my own, not official Red Hat policy
> and so
on.
>
> On 05/17/2012 07:19 PM, Waltermire, David A. wrote:
>> Kurt,
>>
>> My assumption is that each organization would stand up a content
>> repository based on this specification for their own authoritative
>> content, content they produce. They would sign the content using
>> their own private key. I haven't worked 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 guys were talking about the central repo
> (although
at some point there has to be a head repo, right?). As far as keys go why
recreate the wheel? Use X.509 and sign stuff, then key distribution is
trivial (use the 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 better 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 central
> registry. Even for a central registry, I feel we aren't there yet.
> Central repository or a registry would mean getting into operational
> aspects, who'll own, manage, control etc., So, limiting it to
> organizational repositories and content providers repository is good
> in my view.]
>
> [DAW2: This is why I am advocating for 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 that produces content is able
> to point to the authoritative content repositories that they use to
> host their content. They can create as many namespaces as needed, by
> using sub-domains within their own domain(s). A SRV record would be
> associated with each sub-domain in this case.]
>
> As far as supporting repo resolution, I am recommending a namespaced
content identifier approach based on DNS names. Many of the security
automation identifiers have reverse DNS names incorporated 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 referenced 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 approach avoids having to create a
root server infrastructure for content repositories.
>
> I'd like to hear other thoughts related to X.509.]
>
> [CHA: I am not sure if I understand the DNS resolution approach 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 qualification
> would not work if I want to pick the content from this repository
> instead of the original author. Not sure if I am making sense :) ]
>
> [DAW2: I am modeling this approach after DNS. There are authoritative
content servers that originate content. The DNS SRV records would be mapped
to the DNS namespaces hosted by a given authoritative content server. This
is an analog to domains hosted by an authoritative DNS server. Here is a
basic communication flow:
>
> 1) Client: sends request for content by ID to local, organizational
content repository.
> 2) Organizational repository: retrieve the requested content
> a) If the namespace is a local namespace, return the content.
> b) If the namespace is a foreign namespace, check if the content is
> in
the local cache.
> c) Lookup the DNS SRV record associated with the ID's namespace.
> d) Dispatch a request to the foreign 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) Organizational repository: respond to the client with the content
>
> This approach allows content for a given namespace to be managed by a
single 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
repository.
>
> Access to local cache can (and probably should) be limited 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
>> allow 3rd parties to sign content. Again, I have not worked out how
>> best to do this. Any ideas?
>
> Chained signatures would be really nice, e.g. Linux vendor releases an
> RPM
with signed files, customer can then certify them and sign them, so if you
allowed people to 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
signatures "At the same level" is significant, and can be fudged using
signature chains.
>
> [DAW: agreed.]
>
>> Related to restricting access to content, it is my hope that content
>> is made freely available. For some kinds of content, it probably
>> makes 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.
>> Client/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 cert
revocation for expired clients, etc, etc, etc.) and something to be left up
to the end vendor/customer that actually wants this. Building in DRM is a
huge amount of effort and I suspect it would mostly be wasted. Any content
management you build in will:
>
> 1) be incompatible (and thus either removed, or an active problem) for
> many vendors/customers (I doubt any existing system for selling
> content will end up being super compatible with what you guys build)
> 2) be unnecessary 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 scope of this type of problem check out
> http://www.candlepinproject.org/ which provides subscription and
> entitlement management. Even without reinventing the wheel, but just
integrating with something like candlepin would be a huge effort. I would
say this problem is left 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
> and
not worth it. Anyone that wants to sell this kind of thing already has
systems capable of delivering files and managing access/rights to them.
>
> [DAW: Points well taken. I am interested in other thoughts on how
> best to address this. What I was recommending was looking more
> towards service authentication and less towards DRM. Maybe we don't
> address this in the first pass. Thoughts?]
>
> [CHA: Access control is definitely a requirement for organizational
content server as well as content providers repository. Once the service is
authenticated, it should be left to the implementers to define/implement
their own access rights. Because, an entity communicating with the
repository will not see any difference in the behavior.
>
> In our repository, we have implemented a policy driven access control
> and
the policy parameters are the attributes of SCAP metadata. But, someone 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 if one is not allowed to fetch the
> content?]
>
> [DAW2: agreed. I see this as a minimal standardization approach.]
>
>> I hope this answers your questions.
>>
>> Sincerely, Dave
>>
>>
>> -----Original Message----- From: Kurt Seifried
>> [mailto:[email-masked]] Sent: Thursday, May 17, 2012 9:11 PM
>> To: Waltermire, David A. Subject: Re: [scap-dev] [sacm] Request for
>> participants - Content Repository Specification Development
>>
>> On 05/17/2012 04:44 PM, Waltermire, David A. wrote:
>>> Good points. It makes sense to use the mechanisms provided by XML
>>> (e.g. XMLDsig, XML Encryption) 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 restrict access to content. This may also need to
>>> be integrated into the underlying transport.
>> I have some questions, asking off list, not sure if they are
>> appropriate, if they are feel free to reply on the list.
>>
>> 1) if using XMLDsig who would be the signing authority? How secure
>> would signing be (e.g. using a hardware card/appliance/etc?).
>> Where would the key be published/would it be signed/etc? 2) You
>> mention restricting access to content, why would the content need to
>> be restricted? Are there IP issues I am unaware of?
>>
>> Thanks
>>
>>> Sincerely, Dave
>>
> - - --
> Kurt Seifried Red Hat Security Response Team (SRT)
> PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQIcBAEBAgAGBQJPtbFIAAoJEBYNRVNeJnmTuwsQANiygjm9i8AAjiwXMWb3K/RZ
> uIcqM+kbO18cFIWce7p5njzcmRx2eeFFpmMfMTWPrfs7AMjSRjpGy9DNQ9wvlIyR
> GVgwpeWiIK3cZJza3YFEhUfpng3Ivek3kp3nKDgTgm7wBATi0NrRMG6/QRPxxJnK
> MXPjON4aenqInIFxRGoDqplR7e6g6RXuaD4B376f+LC0R7j8lWUK4ug/GTkBPkXf
> LfDuY1Q4u9ctB+tXWQyCwRe4sQ2Gd+PXYzyDENa9kd3e5P/6LTWn3spZQvfEa0Ew
> xQj8YB5VbsyT39GvtlJOV0cJ35HOZBGhwtqwa3vJ6xE3sWCNuJdWqvHr7T8A0Qus
> u4VO6Gc6S6Nrq6DbU9tn11jMoDwwP1wtqFx+l9bhhzSw5VNKVnkTq7/Q0fXd9Q2r
> GfPp0ZplyL4lRfhfglt/dKbGPOoiOhuFXKeJw9MVQRU0ZHRKxnpw+DeFoBCQXpUH
> TdHBg7gu37yB/dAxs63CZKlC1GDi8nXNZ4+myTDDsnqogzbkP61p3acoYFuunLGK
> +JMj0f3OktzZRFqylUbrqw/ONHO5zvZOjZp6pQAikG9Vvn89PsmuXHZvbNJRlaqi
> oiTDzeONz3yyvwjEYg5J1i11e+tzM6x248ulclh+82CwhKL9G1AotFIi803iXrbv
> XCldnHSPS6O7qeRTgMtL
> =QJsL
> -----END PGP SIGNATURE-----
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
_______________________________________________
sacm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sacm
_______________________________________________
sacm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sacm
_______________________________________________
sacm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sacm

---

From: [email-masked]
Date: Thu, 14 Jun 2012 18:38:34 -0500 (CDT)

To all:

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

David Oliva (Ruben)

On 06/14/12, Chandrashekhar B<[email-masked]> wrote:

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: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
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 <[email-masked]>
To: David Waltermire <[email-masked]>, SCAP-DEV <[email-masked]>, "sacm@ietforg" <[email-masked]>
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:[email-masked]]
Sent: Tuesday, May 08, 2012 10:44 AM
To: Kinney, Michael A; SCAP-DEV; [email-masked]
Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA

Mike,

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

Regarding content management, we are building the prototype content repository for use in a production environment.  As an open source project, it will be free for use by anyone interested.  My thinking is that this project can bridge the gap until commercial solutions are available to augment it.  This is a similar path that was followed with DNS (bind) and HTTP (apache).  When it is ready for use, I am hoping to use it to host USGCB content.  You would be welcome to use it for your needs.

It is good that OCIL is moving forward.  This is an important piece of supporting risk management and aspects of continuous monitoring.  I would also like to see some discussion on OCIL at Developer Days.  With the proposals we will likely have a sense of what needs to be discussed and what we can achieve consensus on outside the meeting.

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

We just published the draft ASR specification for public comment.  This specification supports enterprise aggregate reporting which greatly reduces the data volumes needed verses detailed host-based reports. This specification has been designed as a more robust replacement for LASR  It can be used in continuous monitoring applications to support aggregate data reporting needs (e.g. FISMA reporting,  CyberScope).

Here are the links:

http://csrc.nist.gov/publications/PubsDrafts.html

http://csrc.nist.gov/publications/PubsNISTIRs.html#NIST-IR-7848

The primary reason we have suggested waiting on XCCDF is not the internationalization issue. Many vendors have commented that they are still working on implementing the XCCDF 1.2.1 specification. We will be in a better place in a few months once more development around XCCDF has occurred.  As we consider changes to the SCAP stack to address OCIL and other issues, we will identify areas that need improvement in XCCDF.  These are good and necessary discussions to have now, but we have a good deal of work to do before we are ready to open up XCCDF.  My suggestion is to work on these related areas and then work up change proposals for XCCDF as needed.  By that time we should be ready to work on a new revision of XCCDF.

I am also looking forward to the discussions at the conference.  It has been too long.

Sincerely,

Dave

From: Kinney, Michael A [mailto:[email-masked]]
Sent: Tuesday, May 08, 2012 7:09 AM
To: SCAP-DEV
Cc: Waltermire, David A.
Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA

Kent,

It’s good to read your thoughts, and a realistic actionable approach is indeed needed  Since all the activity hasn’t been on the lists a brief 1Ž2 hour recap may be in order to bring everyone up to speed since there has been a lot of activity on CPE/SWID, OCIl, MAEC/CybOX CEE and others.

We could write a content repository specification, but without someone willing to stand one up it will be as valuable as the CCSS specification is today.  I’ve been trying for two years to get my management to get a coordinated effort together for the DoD to stand up a repository, it is a tough problem and will require funding with a tail, I’m not sure a specification will solve that problem.

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

Remediation is stalled but I’m making every effort to get it kick started from our perspective. I hope to assist in getting the draft ERI finished this year.  We are writing some new STIG content and intend to used the draft CRE specification to insert CRE into the content so we (DoD) can do some automatic configuration fixes, part of a self healing network concept. It is just a start but the best we can do at this point.

Enterprise reporting is an interesting subject, since XML adds size to and content to roll up reporting, in any enterprise of size the problem gets greater, I look forward to your thoughts on that subject.

I am concerned that the internationalization efforts are detracting from efforts to meet use cases, we have some things we would like changed in XCCDF to support our OCIl use case and I have been told that I need to wait. I didn’t think that a move to internationalization should impede efforts to move forward with use cases.

I look forward to talking with you at the conference.

v/r

Mike Kinney

Project Director

Computer Network Defense Research and Technology (CND R&T) Office

9800 Savage Road Ste 6767
Ft Meade, MD 20755-6767
Phone: 410-854-4422
NSTS: 968-8886
Fax 410-854-4681

[email-masked]

From:[email-masked] [mailto:[email-masked]] 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

[email-masked]

From:[email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, May 07, 2012 4:25 PM
To: SCAP-DEV
Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer 2012 at MITRE in Bedford, MA

All,

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

I see this appears to follow a path we have discussed in the past as the way not to hold a Dev Days event.  We have been trying to get away from 'Death by Powerpoint' and back to the type of event we held years ago when we were highly productive.  In the past we had a topic to be discussed and a time box to work within.  That allowed us to have very active brainstorming sessions in a high bandwidth environment.

At past Summer events we have got into a pattern of lots of powerpoint, lots of status of the efforts and very little discussion about things that need active discussions.  We need to keep moving forward and making progress as an effort. We can get status from various places such as the lists, a presentation being sent out in advance, a webinar if it is felt there will be questions and answers from those that are new to the efforts.  We have a limited amount of time and all who are attending are investing a great deal of time and money to be there.  We should not  be spending a great deal of time reeducating everyone when we could be focused on advancing needed efforts.

The type of approach to a Dev Days event was discussed at the last Summer Dev Days.  I have seen the following work quite well in other efforts.

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.

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 <[email-masked]>
Reply-To: "OVAL Developer List (Closed Public Discussion)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
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:[email-masked]]
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 [[email-masked]]
Sent: Tuesday, March 20, 2012 16:38
To: [email-masked]
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

[email-masked]

To unsubscribe, send an email message to [email-masked] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [email-masked].

To unsubscribe, send an email message to [email-masked] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [email-masked].

To unsubscribe, send an email message to [email-masked] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [email-masked].