Re: [scap_interest] Scope of standards potentially moving to IETF

[<[e-mail]>]

  Would IETF also take a role in validating products?

Validated SCAP products today does not mean interoperable products and that is part of the problem existing in the community today. We have fallen into a false sense that if a product have been validated, then it is interoperable with the other SCAP products.  That is not the case.  What occurs in the validation process is a certain set of functionality and features are checked.  The entire set of specifications have not been.  For example: over two years ago there was a section of FDCC content that caused serious problem with domain controllers and affected the network in general.  A vendor found the issue, investigated what was causing the problem and then fixed and tested the solution.  The tested fix was then sent to the FDCC content maintenance team to be corrected in the FDCC content.  Instead of fixing the problem, they disabled the checks because they could not make the fix available.  The reason?  Not all vendors that were SCAP Validated had implemented the needed tests required by the OVAL specifications to use the fix…   These were core tests… That said, the validation program is now going to be testing the specifications more completely which should help.  There is a place for product capability validation and I don't see that going away anytime soon but it still does not assure interoperability.

I have been discussing interoperability testing between vendors for a while now.  That is where you see if you have real compatible products.  In that case, I give you my content and you give me your results in consumable SCAP results formats and visa versa.  The IETF's history of bake offs and interop testing between products would be a real step in the right direction.  This would also encourage vendors to implement the complete specifications in their products instead of just what is needed to "pass the test".

Interoperability is the real goal if we are looking to lay a foundation of plug and play security automation capabilities…

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: Sean Turner <[e-mail]<mailto:[e-mail]>>
Date: Thu, 16 Feb 2012 06:58:06 -0600
To: Adam Montville <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: Michael Aharon Chernin <[e-mail]<mailto:[e-mail]>>, Kent Landfield <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [scap_interest] Scope of standards potentially moving to IETF

(assuming there is a WG) It's mostly up to the WG.  There's still
IETF-wide, IESG and external party review of WG charters.

More inline below ...

spt

On 2/15/12 11:50 AM, Adam Montville wrote:
Hi David,

I think the answer to all three of your questions is really that it's all up to the working group.  The WG has an interest in ensuring interoperability, and standards are created based on running code.  USG may continue to require validation outside the context of the WG.  Finally, as the IETF is an open organization, participation from any organization, including USG, would be welcomed.

Adam

From:<[e-mail]<mailto:[e-mail]><mailto:[e-mail]>>
Date: Wed, 15 Feb 2012 10:42:34 -0600
To:<[e-mail]<mailto:[e-mail]><mailto:[e-mail]>>, kent_landfield<[e-mail]<mailto:[e-mail]><mailto:[e-mail]>>,<[e-mail]<mailto:[e-mail]>>
Subject: Re: [scap_interest] Scope of standards potentially moving to IETF

Hello all:

I also believe that SCAP can be used worlwide and should be marketted accordingly.
Maybe allowing IETF to endorse them is a good idea.

I just have a few questions.

1.  Would IETF also take a role in validating products?

Some lurking greybeards may correct me, but I can't think of a time when
the IETF validated products - but maybe that depends on what you mean.
I can think of many bake-offs/interop events and reports of such events
that listed product x, y, and z and whether they interoperated on tests
a, b, and c.  If by validation you're thinking a letter/certificate from
the IETF saying product x is compliant with RFC ####, then I think that
won't happen.

2.  What mechanisms does IETF provide that encourage the cooperation needed for incorporation future specifications?

An open, consensus driven standardization process would be my answer.
List are open to anyone and drafts/RFCs are available for free.

3.  How would IETF take into account the input of U.S. Federal agencies in future specifications?

On USG participation, all participants in the IETF (including those of
the USG or any other Gov't) participate as individuals.  They're free
(in fact encouraged) to bring in-scope proposals to the WG.  Assuming
there's a debate about a particular feature/option in their proposal,
I'd expect them to defend their proposal just like everybody else does.
  Rationale like "We're the USG and you shalt do it this way" isn't
going to fly.  Rough consensus will rule the day.

David Oliva

On 02/15/12, Chernin, Michael A.<[e-mail]<mailto:[e-mail]><mailto:[e-mail]>>  wrote:

Kent, understood. Like the vendors, I do agree that certain standards need to go to IETF. But, today the only people that would be voting during IETF calls would be the federal government and security tool vendors. I am going to be hesitant in supporting a move of all standards until there are standards consumers (private sector customers) who will also be participating in IETF voting. I am trying to balance rapid development of standards using the IETF and complete vendor control of all standards. Once I see more consumer activity during voting, I will be more supportive of a large number of standards moving IETF.

I know I am early and jumping the gun on this, but I just wanted to get my story out there. At this time no standards have been specifically identified and no specific action is required at this time.

Aharon

DTCC Non-Confidential (White)
---------------------------------------------------
Michael "Aharon" Chernin
Security Automation Program Manager
Corporate Information Security -Depository Trust&  Clearing Corporation
O: 813-470-2173

From: [e-mail]<mailto:[e-mail]><mailto:[e-mail]>  [mailto:[e-mail]]
Sent: Tuesday, February 14, 2012 6:09 PM
To: Chernin, Michael A.; [e-mail]<mailto:[e-mail]><mailto:[e-mail]>
Subject: Re: [scap_interest] Scope of standards potentially moving to IETF

>From my perspective TBD.

There are some that are unencumbered from and IPR perspective and those are potential candidates. Others will have to move as the appropriate consensus  is achieved and IPR issues are addressed.

The idea here from my perspective is to figure that out.

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: Michael Aharon Chernin<[e-mail]<mailto:[e-mail]><mailto:[e-mail]>>
Date: Tue, 14 Feb 2012 16:04:43 -0600
To: "[e-mail]<mailto:[e-mail]><mailto:[e-mail]>"<[e-mail]<mailto:[e-mail]>>
Subject: [scap_interest] Scope of standards potentially moving to IETF

I am just going to jump right on out there and ask. Which standards are we looking to go to IETF? Specific SCAP standards or the entire SCAP umbrella?

Aharon

DTCC Non-Confidential (White)
---------------------------------------------------
Michael "Aharon" Chernin
Security Automation Program Manager
Corporate Information Security -Depository Trust&  Clearing Corporation
O: 813-470-2173

<BR>_____________________________________________________________
<FONT size=2><BR>
DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or
entity to whom they are addressed. If you have received this email
in error, please notify us immediately and delete the email and any
attachments from your system. The recipient should check this email
and any attachments for the presence of viruses.  The company
accepts no liability for any damage caused by any virus transmitted
by this email.</FONT>
_______________________________________________
scap_interest mailing list
[e-mail]<mailto:[e-mail]><mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/scap_interest


________________________________

_______________________________________________
scap_interest mailing list
[e-mail]<mailto:[e-mail]><mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/scap_interest
_______________________________________________ scap_interest mailing list [e-mail]<mailto:[e-mail]><mailto:[e-mail]>  https://www.ietf.org/mailman/listinfo/scap_interest

_______________________________________________
scap_interest mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/scap_interest