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

["Chandrashekhar B" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of
[e-mail]
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: [phone]
Web: www.mcafee.com <http://www.mcafee.com/> 

 

From: <Kinney>, Michael A <[e-mail]>
To: David Waltermire <[e-mail]>, SCAP-DEV
<[e-mail]>, "sacm@ietforg <mailto:[e-mail]> " <[e-mail]>
Subject: Re: [sacm] [OVAL-DEVELOPER-LIST] Security Automation Developer
Days: Summer 2012 at MITRE in Bedford, MA

 

Dave,

I have no problem with webinars, I do want to keep developer days actionable
and use it to make decisions, and vote and accomplish things good or bad.  I
do not want this to be an informational briefing conference.

Thanks for the links.

 

I still think that any specification for a repository is wishful thinking
until someone builds one and learns the lessons it will just be another
whitepaper spec.  I believe the DoD needs to incorporate a metadata
repository as part of it and other customizations that may not be useful for
everyone.

We need to talk more.

 

-Mike  

 

From: Waltermire, David A. [mailto:[e-mail]] 
Sent: Tuesday, May 08, 2012 10:44 AM
To: Kinney, Michael A; SCAP-DEV; [e-mail]
Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days:
Summer 2012 at MITRE in Bedford, MA

 

Mike,

 

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

 

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

 

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

 

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

 

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

 

Here are the links:

 

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

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

 

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

 

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

 

Sincerely,

Dave

 

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

 

Kent,

 

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

 

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

 

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

 

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

 

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

 

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

 

I look forward to talking with you at the conference.

 

v/r

 

Mike Kinney

Project Director

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

9800 Savage Road Ste 6767
Ft Meade, MD 20755-6767
Phone: [phone]
NSTS: 968-8886
Fax [phone]

 <mailto:[e-mail]> [e-mail]

 

 

 

From:[e-mail] [mailto:[e-mail]] On Behalf Of Waltermire,
David A.
Sent: Monday, May 07, 2012 7:09 PM
To: Multiple recipients of list
Subject: RE: [OVAL-DEVELOPER-LIST] Security Automation Developer Days:
Summer 2012 at MITRE in Bedford, MA

 

Kent,

 

I like what you are saying here.  We are also in support of this type of
approach.  We would like to see some community discussion around what are
the key areas/priorities that the community would like to see discussed at
Dev Days.  Your topics below look like a good start. The SACM list might be
a better venue than the OVAL list for this discussion.  For each area we
should focus the discussion around developing objectives for each session.
The sessions can be time boxed based on what would be a reasonable amount of
time to accomplish each objective.  For example if continuous monitoring is
a priority and collectively it takes 3 days to work through all the
objectives, I see no problem with that.  We can also keep a few sessions "on
deck" if all the objectives are reached and we complete all the scheduled
sessions early.

 

Thoughts?

 

Sincerely,

 

David Waltermire

SCAP Architect

National Institute of Standards and Technology

[phone]

[e-mail]

 

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

 

All,

 

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

 

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

 

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

 

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

1.	Presentations are sent out to the attendees and the lists a week in
advance
2.	Status for any effort is limited to 30 minutes
3.	Focused brainstorming time should be established for certain areas
that need real work by the community
4.	Efforts to be discussed should be based on needs of the security
automation space to move existing efforts to completion.

For example:

 

Continuous monitoring is a major direction the efforts are becoming involved
with. There are going to be things we need to do as a security automation
community to be able to accomplish what is listed in the CAESARS FE.  There
are interfaces that need to be worked and established.  That is one area
that is not listed below.  CM will have a major impact on all of us in the
next couple years and it is being ignored.  We can't keep trying to solve
what has already been solved.  We need to address the needed interface
development now. This is an effort that could take nearly a whole day by
itself.

 

Operationally we have a real need to be able to deliver SCAP content
internally within an organization. Today the SCAP vendors cannot share a
single local site security policy (XCCDF + OVAL + CPE +.) without the site
staff having to go to each of the individual products and figuring out how
to inject that new or updated policy into that products delivery mechanisms.
That is limiting sites from wanting to buy multiple focused SCAP products
since they are such a pain to manage from a content perspective.  It is
easier to buy from one vendor that has a single means for distributing
content than it is to deal with the management issues that having multiple
SCAP products presents.  We need to have at least an entire 1/2 a day on the
development of a Content Repository specification.

 

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

 

I am really disappointed that Remediation is not on the list below.  Yes,
last Summer Dev Days, the time spent on Remediation was wasted time but that
does not mean we should ignore it and not try to make some real progress.
As far as I am concerned we need to reboot the remediation effort.  We
cannot keep being the set of specifications / tools that act as the little
boy crying "Wolf" in the night.  We need to be able to find and fix issues
if we are going to really make a difference in organizational security
postures.  But today we think it is too hard so we don't try ?  I think we
need a couple hours to discuss the reboot of the effort even if that means
minimizing work already done.

 

A focused discussion on enterprise reporting is also critically needed.  For
the vendors here, we have all gone through the Cyberscope goat rope,
delivering limited capabilities to specific data call requirements of the
Federal Agencies.  The initial effort was a mess, did little more than prove
it was possible and cause the vendor community a great deal of thrashing to
put a kludgey 'solution' in place.  Reality is all our customers need roll
up reporting and an infrastructure that supports it.  A data call should not
be special to anyone other than the agencies responding. The tools should be
able to select the types of data needed and deliver that on a scheduled
basis automatically.    Enterprise Reporting pertains to commercial as well
as Federal customers.  We need to focus some time on what that would look
like using the ARF and ASR as the foundational pieces.  But there are
missing pieces..  We need this discussed.

 

I would hope we can make this summer's SCAP Dev Days useful in advancing the
security automation efforts by addressing some of the more critical issues
our customers are facing now or will be facing in the very short term.
Status presentations are not interesting to those active in the efforts.
Let's try to do those before we get to Bedford so we can real make some
progress while we are all in the same room.  This is always a big event for
the 'consensus of the willing' that assemble and driven to see security
automation make a difference.  Let's see if we can have an event that, when
we all walk out the last day, we all feel that every minute was well spent
and moves us forward.

 

Thanks.

 

Kent Landfield
Director Content Strategy, Architecture and Standards

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

Direct: +1.972.963.7096 
Mobile: [phone]
Web: www.mcafee.com <http://www.mcafee.com/> 

 

From: <Boczenowski>, Steve <[e-mail]>
Reply-To: "OVAL Developer List (Closed Public Discussion)"
<[e-mail]>
To: "[e-mail]"
<[e-mail]>
Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days:
Summer 2012 at MITRE in Bedford, MA

 

Frank;

 

We hope to have the registration site up next week.  The event will be
during the week of July 9 - starting Monday at 10:00 AM and ending on Friday
at 12:00.

 

Meanwhile, we are working on the agenda and are currently considering this
list of topics:

 

CCE

CPE/SWID

CEE

XCCDF

OVAL

ASR

Enterprise OCIL

CybOX/MAEC

Federated Content Repository Spec

Endpoint Reporting for Continuous Monitoring and Compliance (ERCC)

MILE

TAXII

IF-M for SCAP

IF-MAP

SCAP Releases

SCAP and IETF

NETCONF and SCAP

 

Steve

 

From: Frank Lindsay Acker [mailto:[e-mail]] 
Sent: Tuesday, May 01, 2012 9:32 AM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] Security Automation Developer Days:
Summer 2012 at MITRE in Bedford, MA

 

Steve....

Has there been any additional information regarding this event?

Thanks,
Frank Acker


  _____  


From: Boczenowski, Steve [[e-mail]]
Sent: Tuesday, March 20, 2012 16:38
To: [e-mail]
Subject: [OVAL-DEVELOPER-LIST] Security Automation Developer Days: Summer
2012 at MITRE in Bedford, MA

Save the Date: week of July 9, 2012

 

This year's MITRE-hosted Security Automation Developer Days event will be
held during the week of July 9, 2012 at MITRE's facility in Bedford, MA.

 

Details to follow.

 

Regards,

    Steve

 

______________________________________________

Stephen P. Boczenowski

      The MITRE Corporation

      Office: [phone]

      Cell: [phone]

     [e-mail]

 

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

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

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