SPC-4 Add Security Protocol page for reporting security compliance (T10/11-102)

James C Hatfield james.c.hatfield at seagate.com
Thu May 19 12:05:13 PDT 2011


Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1105197_f.htm">HTML-formatted message</a>

In response to Kevin Butt's question....
The reasons that Seagate only pursued specification (in T13) of a FIPS 140
descriptor are several:
1) that's the only one that people were really interested in
2) start small: define an extensible reporting mechanism and let it grow
over time, as needed
3) don't specify things that aren't required (yet): unused reports tend to
become checklist requirements
    and are not always appropriate
Thank You !!!
-----------------------------------------------------------------
Jim Hatfield
Seagate Technology LLC
   e-mail:  James.C.Hatfield at seagate.com
   s-mail:  389 Disc Drive;  Longmont, CO 80503 USA
   voice:  720-684-2120
   fax....: 720-684-2711
   cell...: 720-771-8914
On Thu, May 19, 2011 at 12:27 PM, Ballard, Curtis C (StorageWorks) <
curtis.ballard at hp.com> wrote:
> Kevin,
>
>
>
> I wondered about the “may or may not be operating in the mode specified”
> statement as well but decided that I like it in the FIPS specific section
> better as that gives us more flexibility.  I think it is entirely possible
> that some other security certification could come along that prohibits
> reporting certificate information when not operating in the specified mode
> or that there may be some certification where the device is always
operating
> in the specified mode.  With the statement in the FIPS specific section any
> other descriptors could have different rules.
>
>
>
> Curtis Ballard
>
> Hewlett Packard
>
>
>
> *From:* owner-t10 at t10.org [mailto:owner-t10 at t10.org] *On Behalf Of *Kevin
> D Butt
> *Sent:* Thursday, May 19, 2011 10:42 AM
> *To:* Gerry Houlder
> *Cc:* owner-t10 at t10.org; T10 Reflector
>
> *Subject:* Re: SPC-4 Add Security Protocol page for reporting security
> compliance (T10/11-102)
>
>
>
> Gerry,
>
> I like the change to 7.7.1.5.2 FIPS 140 compliance descriptor that makes it
> clear that this certificate applies to the device, but the use needs to
> ensure that the correct mode is being used.
> The FIPS 140 compliance descriptor (see table new3) contains information
> that may be used to locate information about a FIPS 140 certificate
> associated with the device. The device may or may not be operating in the
> mode specified by that certificate.
>
> However, I wonder if the statement, "The device may or may not be operating
> in the mode specified by that certificate." belongs in the overview (i.e.,
> 7.7.1.5.1 Security compliance information overview)?	While only the FIPS
is
> currently listed will we need the same statement in each additional type
> added - or does this need examined on a case by case basis?
>
> As it stands now, this resolves my objections.
>
> Thanks,
>
> Kevin D. Butt
> SCSI & Fibre Channel Architect, Tape Firmware
> Data Protection & Retention
> MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
> Tel: 520-799-5280
> Fax: 520-799-2723 (T/L:321)
> Email address: kdbutt at us.ibm.com
> http://www-03.ibm.com/servers/storage/
>
>
>
> From:        Gerry Houlder <gerry.houlder at seagate.com>
> To:	     T10 Reflector <t10 at t10.org>
> Date:        05/19/2011 09:13 AM
> Subject:	  Re: SPC-4 Add Security Protocol page for reporting
> security compliance (T10/11-102)
> Sent by:	  owner-t10 at t10.org
> ------------------------------
>
>
>
>
> The discussion at the CAP meeting was riding a fine line between "not
> guaranteeing compliance just because the notice is returned" and "having so
> many mays that the notice is useless". The sentences quoted by Paul were
> already greatly relaxed from the wording discussed in CAP and rejected at
> the plenary meeting. I invite all those that voted no at the plenary to
> review rev. 2 of the proposal to see if that wording satisfies their
> concerns. Note that there are change bars to reflect changes requested at
> the CAP meeting and after the plenary (by Curtis and David Black)  and I
> hope the other interested parties will also see the changes as satisfying
> their concerns.
>
> On Wed, May 18, 2011 at 7:09 PM, Ballard, Curtis C (StorageWorks) <
> curtis.ballard at hp.com> wrote:
> Paul,
>
>
>
> Thanks for the thoughts.
>
>
>
> Gerry Houlder (Seagate), David Black (EMC), and myself (Curtis Ballard, HP)
> got together following the plenary meeting last week and worked on wording
> that would make it more clear that the descriptors describe a security
> certificate that “Applies To” the device and that the device “may or may
> not” be operating in the mode described by the certificate.  That wording
> was not there following the CAP review.
>
>
>
> It looks like Gerry has already incorporated those changes in the revision
> posted and the one you reference.
>
> http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-102r2.pdf
>
>
>
> With those revisions I am satisfied that there is sufficient guidance for
> what the descriptors mean.  I don’t feel that adding additional “may”
> statements is necessary.
>
>
>
> Curtis Ballard
>
> Hewlett Packard
>
>
>
>
>
>
>
> *From:* owner-t10 at t10.org [mailto:owner-t10 at t10.org] *On Behalf Of *Paul
> Suhler*
> Sent:* Wednesday, May 18, 2011 5:27 PM*
> To:* T10 Reflector*
> Subject:* SPC-4 Add Security Protocol page for reporting security
> compliance (T10/11-102)
>
>
>
> Hi, everyone.
>
> At last week’s plenary, we decided not to go forward with the revision of
> Gerry’s proposal approved in CAP.  Instead we said that we’d discuss
> alternative wording that would be acceptable.
>
> The issue was that (if I recall correctly) we’d like to be able to report
> this descriptor even if the firmware running in the device had been neither
> submitted nor approved as complying with the cited standard.	In such a
> case, if the SPC-4 wording requires that the standard applies to the
device,
> then reporting the descriptor might be considered inaccurate or misleading.
> I think that we want to report the actual Hardware Version, Version, and
> Module Name of the device, which may not appear on the compliance
> certificate on the NIST (or other agency) web site.
>
> One possible change would be to scrub the proposal and use “may” wherever
> appropriate.	For example, in the latest revision (
> http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-102r2.pdf), the first sentence
> in 7.7.1.5.1:
>
> “The security compliance information page contains information about
> security standards that apply to this device.”
>
> Would change to:
>
> “The security compliance information page contains information about
> security standards that may apply to this device.”
>
> The first paragraph of 7.7.1.5.2 already seems weaselly enough:
>
> “The FIPS 140 compliance descriptor (see table new3) contains information
> that may be used to locate information about a FIPS 140 certificate
> associated with the device. The device may or may not be operating in the
> mode specified by that certificate.”
>
> Then,
>
> “The REVISION field is an ASCII character (see 4.4.1) that indicates the
> FIPS 140 revision that applies to the device (see table new4).”
>
> Could change to:
>
> “The REVISION field is an ASCII character (see 4.4.1) that indicates the
> FIPS 140 revision that applies may apply to the device (see table new4).”
>
> Etc., etc. for the other fields.  Perhaps we change “…as reported by NIST.”
> to “… which may be reported by NIST.”  ?
>
> Do we also need to explicitly state up front that the device may or may not
> comply, and that the information in the descriptor should be checked
against
> the certifying agency’s web site to determine compliance?
>
> Please share your thoughts.
>
> Thanks,
>
> Paul
>
> *
>
_____________________________________________________________________________
________________________
> *
> Paul A. Suhler | Firmware Engineer | Quantum Corporation |
Office:949.856.7748 |
> paul.suhler at quantum.com *
> Preserving the World's Most Important Data.** **Yours**.™*
>



More information about the T10 mailing list