attachment-0001

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    At the 12th ICCC, I was asked to share some of the hardcopy devices
    community's experience and recommendations for technical community
    terms of reference. I submitted them to Dag Ströman, the head of the
    Swedish CC scheme and also chair of the CC Management Board, and to
    Matsutoshi Murata of the Japanese CC scheme. I have not yet received
    any feedback.<br>
    <br>
    What I submitted was:<br>
    <ol>
      <li>An outline of the IEEE P2600 Working Group that developed the
        Hardcopy Devices PPs; and</li>
      <li>My recommendations for CCDB Collaborative TC ToRs, based on
        experience with that group, the CCDB Vision paper, discussions
        with others, David Martin's presentations, etc. </li>
    </ol>
    For each, I used the same topical outline (except for Issues and
    Results, in the case of IEEE P2600). <br>
    <br>
    I had hoped to make a very short set of ToR recommendations, but
    there really are quite a few things to address. I've tried to limit
    the number of "musts" and used "shoulds" wherever I could. But it's
    not as bad as it looks.<br>
    <br>
    I am hoping that something along the lines of this proposal will be
    accepted by the CC Development Board as the way to organize
    Technical Communities for developing Protection Profiles and 
    Supporting Documents. But who knows? Please send me your comments...<br>
    <br>
    By the way, we're probably going to start setting up a Technical
    Community for hardcopy devices in January, so this is kind of
    important.<br>
    <br>
    <br>
    <b>IEEE P2600 WG</b><br>
    <ul>
      <li>Initiation</li>
      <ul>
        <li>It was initiated by a group of vendors who held a
          pre-formation meeting and then applied to the IEEE Standards
          Association (IEEE-SA) to form a working group. Subsequent
          meetings were as an IEEE working group. Web site: <a
            class="moz-txt-link-freetext"
            href="http://grouper.ieee.org/groups/2600/">http://grouper.ieee.org/groups/2600/</a><br>
        </li>
      </ul>
      <li>Incorporation</li>
      <ul>
        <li>P2600 is a working group of the IEEE-SA and is therefore
          incorporated under the IEEE-SA.<br>
        </li>
      </ul>
      <li>Membership</li>
      <ul>
        <li>Open to anyone (even non-IEEE members), as individuals.
          Although individuals were usually representing a vendor,
          IEEE-SA working group members participate as individuals and
          issued standards list them as such, without associating them
          with their employers.</li>
        <li>Vendor representatives were the core participants, although
          untold others lurked on the mailing list. Sometimes the
          lurkers would offer answers or guidance on topics, so it was
          useful to have them.<br>
        </li>
        <li>Schemes and labs and consultants participated in some
          meetings, and on some occasions we specifically invited them
          to attend.</li>
      </ul>
      <li>Meetings</li>
      <ul>
        <li>We held face-to-face meetings every six weeks. There were
          some special occasions for teleconferences, sometimes
          involving only an ad hoc committee that had been formed and
          announced in a previous meeting. We made few exceptions for
          the face-to-face requirement -- generally only for invited
          guests or for members who would need to travel from Asia or
          Europe.</li>
        <li>Travel budgets were looser then than now. The bulk of our
          work was completed before the economic collapse in 2009.<br>
        </li>
      </ul>
      <li>Technical infrastructure</li>
      <ul>
        <li>We have a web site and several mailing lists, provided by
          the IEEE-SA.</li>
      </ul>
      <li>International-friendliness</li>
      <ul>
        <li>Most members were from the US, but some from Canada, Europe,
          and Asia.</li>
        <li>Most of the Asian vendors used their US representatives to
          participate. I think this was more of a language and cultural
          decision than one of international accessibility.</li>
        <li>Most of our face-to-face meetings were held in the US or
          Canada, but we did have at least one in Europe and Japan. On
          those occasions when we had teleconference calls, we made sure
          that they were at an acceptable time and day for the expected
          participants.<br>
        </li>
      </ul>
      <li>Organization</li>
      <ul>
        <li>We had an elected chairperson, vice-chairperson, and
          secretary. These positions had a one-year term with no limits.
          The chairperson need to be an IEEE and IEEE-SA member.<br>
        </li>
        <li>We also had volunteer editors.<br>
        </li>
      </ul>
      <li>Costs and funding</li>
      <ul>
        <li>There was no cost to organize and operate the WG, because
          IEEE-SA is supported by memberships and sales of standards.</li>
        <li>We had to negotiate a license purchase for the PPs so they
          could be made available at no charge and so that derivative
          works (STs) could be created (see below, Ownership).</li>
        <li>We put out an RFP for PP evaluation, chose a lab, and paid
          for PP evaluation and some consulting help.</li>
        <li>Most but not all vendors contributed, equally, to cover
          those costs. The benefits of contributing included quotes in
          press releases from the IEEE, easier licensing for derivative
          works, and listing of certified conforming products on the
          P2600 web site.<br>
        </li>
      </ul>
      <li>Policies and procedures</li>
      <ul>
        <li>We operated under procedures conforming to the rules of the
          IEEE-SA. Details: <a class="moz-txt-link-freetext"
            href="http://grouper.ieee.org/groups/2600/process/OpProcs.doc">http://grouper.ieee.org/groups/2600/process/OpProcs.doc</a></li>
        <li>This was helpful for operating the WG, decision-making, etc.</li>
        <li>It was cumbersome for initiating projects within the WG
          (needed to submit a project authorization request to the IEEE
          Standards Board), and even more cumbersome for publication
          (needed to follow IEEE standards formats, go through an
          editing cycle, and form a separate balloting group to review
          and vote on each PP, then submit the PP to the Standards Board
          for approval as an IEEE Standard -- plus get it evaluated and
          certified per the CC).<br>
        </li>
      </ul>
      <li>Decision-making</li>
      <ul>
        <li>Members who attended two of the most recent four meetings
          could request voting rights. If they did not continue to
          participate, their voting rights could be rescinded.</li>
        <li>Decisions were made based on simple majority, with some
          quorum rules. Since we held face-to-face meetings, there
          tended to be only one voting member from each vendor.</li>
        <li>We never really had any very contentions issues that tested
          the individual vote (versus one vote per company).<br>
        </li>
      </ul>
      <li>Transparency</li>
      <ul>
        <li>All work including mailing list archives, draft documents,
          and meeting minutes, were open to the public -- until we got
          close to final drafts, at which time the IEEE asked us to
          password protect the drafts to protect their copyright on the
          issued standards.<br>
        </li>
      </ul>
      <li>PP evaluation</li>
      <ul>
        <li>PPs were formally evaluated by a lab and overseen by a
          scheme. They were not "evaluated on first use".</li>
        <li>The evaluations were not performed by the same people who
          helped write parts of the PP, which helped ensure that the
          evaluations were done more objectively.<br>
        </li>
      </ul>
      <li>Ownership of work product</li>
      <ul>
        <li>As mentioned before, IEEE-SA held copyright on the PPs and
          expected to sell them. We needed to negotiate a special
          license to allow their free use for CC purposes, but the
          copyright even with that license restricts other uses.<br>
        </li>
      </ul>
      <li>Legal protection</li>
      <ul>
        <li>As a recognized SDO, WG members were protected from being
          accused of collusion. Each meeting was opened with a standard
          presentation slide and statement about topics that were
          inappropriate to discuss in the meetings.<br>
        </li>
      </ul>
      <li>Intellectual property</li>
      <ul>
        <li>We never really worried about revealing trade secrets. The
          primary issue of intellectual property was patents.</li>
        <li>The WG followed IEEE-SA (which follows ANSI) policies about
          essential patents. Members had a duty to reveal any knowledge
          of patents that were essential to conforming to the standards
          under development.<br>
        </li>
      </ul>
      <li>Sustainability</li>
      <ul>
        <li>The issue of work product ownership causes us to consider
          alternatives for future work, but if we wanted to continued
          under IEEE-SA we could do so indefinitely. IEEE has been
          around for a very long time.<br>
        </li>
      </ul>
      <li>Issues</li>
      <ul>
        <li>Work product ownership was the biggest issue. We were
          unprepared for the cost of purchasing the necessary copyright
          license to make the PPs available for use.<br>
        </li>
        <li>Conforming to the IEEE Standards approval process was also
          challenging, but at the time we did want to have some
          recognition of the "officialness" of our PPs, so it did serve
          that purpose.</li>
        <li>We paid for evaluation lab services (and a small fee to BSI
          for certification). The main issue was that we could not get
          firm quotes from labs until we had nearly completed the PPs,
          which meant that we could not inform the vendors about costs
          at the start of the project. However, we did a little survey
          of some labs to get a rough idea of how much PP evaluation
          might cost, and that did turn out to be pretty close to what
          we paid.<br>
        </li>
      </ul>
      <li>Results</li>
      <ul>
        <li>We produced a general standard (available for purchase),
          four evaluated PPs, two of those PPs were certified (one by
          NIAP, the other by BSI, both used atsec as the evaluation
          lab).</li>
        <li>We also produced an informative guide for writing STs based
          on those PPs.</li>
        <li>All are available here: <a class="moz-txt-link-freetext"
            href="http://grouper.ieee.org/groups/2600/how-to-obtain.html">http://grouper.ieee.org/groups/2600/how-to-obtain.html</a></li>
        <li>As of today, twelve certificates have been published on the
          CC portal for conforming products, an additional six are
          completed but published only on the scheme web site, and nine
          more are currently listed as being in evaluation. Each one of
          these evaluation projects typically represents several MFP
          product models.<br>
        </li>
      </ul>
    </ul>
    <br>
    <b>Recommendations for CCDB-approved ToRs</b><br>
    <ul>
      <li>Initiation</li>
      <ul>
        <li>Informal "pre-formation" meetings should be used to attract
          vendors and labs and schemes to the possibility of forming a
          TC. They can be called by any stakeholder.<br>
        </li>
        <li>Note: I don't know what the process or criteria will be for
          the CCDB to approve the formation of a TC, but I imagine that
          the criteria would include:</li>
        <ul>
          <li>At least one scheme must be committed to be the sponsor.
            That scheme should have some history of certifying products
            in the TC's technology area.<br>
          </li>
          <li>More than one scheme should participate, to help ensure
            mutual recognition of the output.</li>
          <li>A majority of vendors must be committed to participate.
            How exactly to determine that may be a problem. If some
            significant vendors decline to participate, the CCDB should
            try to find out if they are doing so out of passiveness or
            due to a specific objection.</li>
          <li>At least one lab must be committed. That lab should have
            some history in evaluating products in the TC's technology
            area.</li>
          <li>More than one lab should participate.</li>
          <li>The proposed TC must follow the required and recommended
            ToRs.</li>
        </ul>
        <li>The formation and approval process itself must be open, with
          public announcements of intent and milestones and such.<br>
        </li>
      </ul>
      <li>Incorporation</li>
      <ul>
        <li>The TC must be incorporated as a legal entity that can hold
          copyright.</li>
        <li>The TC should be recognized as a standards development
          organization (e.g., be incorporated under an SDO) to provide
          anti-trust protection.</li>
      </ul>
      <li>Membership</li>
      <ul>
        <li>Membership must be freely open to anyone with a demonstrable
          interest in subject matter of the TC.</li>
        <ul>
          <li>The TC should reserve the ability to remove members for
            disruptive or inappropriate behavior.</li>
        </ul>
        <li>Membership should be categorized by stakeholder role (e.g.,
          scheme, vendor, lab,...), organization, and representative(s).
          These are used for decision-making processes.<br>
        </li>
        <ul>
          <li>Individual membership (not associated with an
            organization) should be allowed.</li>
        </ul>
        <li>Membership roles should be accessible to members.<br>
        </li>
      </ul>
      <li>Meetings</li>
      <ul>
        <li>Meetings must be announced and conducted according to
          pre-defined rules. Such rules may be defined by the TC itself.
          For example:<br>
        </li>
        <ul>
          <li>Meetings and their agendas are published in advance of the
            meeting.<br>
          </li>
          <li>Meeting summaries or minutes are published for members.</li>
          <li>Action items are recorded and tracked.<br>
          </li>
        </ul>
        <li>Meetings should be held in English language (as the <i>lingua

            franca</i> of the CC).<br>
        </li>
        <li>Face-to-face meetings should be accessible to those who
          cannot attend in person, by live telephone, recording, or
          detailed minutes.<br>
        </li>
      </ul>
      <li>Technical infrastructure</li>
      <ul>
        <li>Minimally, the TC must have a managed email list or online
          forum, and file storage for documents, available to all
          members and restricted from access by others.</li>
      </ul>
      <li>International-friendliness</li>
      <ul>
        <li>The TC must accommodate an international membership.</li>
        <ul>
          <li>Note: Depending on the geographic makeup of the group,
            this may require rotation of meeting times to be fair to
            meeting participants (not necessarily the same as members!).<br>
          </li>
        </ul>
      </ul>
      <li>Organization</li>
      <ul>
        <li>The TC must have a chairperson.</li>
        <ul>
          <li>Note: I am not sure if the CCDB thinks that a scheme
            representative must chair the group, or if they can delegate
            to an elected member, or if it can be fully open to
            election. If the CCDB insists on a scheme rep as chair, they
            need to make that person sufficiently available to be a
            responsible and responsive chairperson.<br>
          </li>
        </ul>
        <li>The TC should have a vice-chair as a backup for the
          chairperson</li>
        <li>The TC should have a secretary to take minutes, manage
          action item lists, manage document storage, etc.</li>
        <ul>
          <li>Note: I have found it to be more consistent if one person
            handles these things. The alternative is to rotate the duty
            or ask for volunteers.<br>
          </li>
        </ul>
        <li>.Officers must be elected by a defined voting process with a
          defined term.<br>
        </li>
      </ul>
      <li>Costs and funding</li>
      <ul>
        <li>The operating costs of the TC must be borne by member
          organizations (not by each representative).</li>
        <ul>
          <li>The membership fee structure should accommodate smaller
            organizations and individual memberships by providing
            reduced fees.</li>
          <li>Free individual membership should be available, but
            without voting or other rights.</li>
        </ul>
        <li>Membership fees should be reasonable, for example under
          US$2,500 per year for large organizations.<br>
        </li>
      </ul>
      <li>Policies and procedures</li>
      <ul>
        <li>The TC must have written policies and procedures for key
          operations. For example:</li>
        <ul>
          <li>Membership</li>
          <li>Voting rights</li>
          <li>Election of officers</li>
          <li>Decision-making</li>
          <li>Making changes to the policies and procedures<br>
          </li>
        </ul>
      </ul>
      <li>Decision-making</li>
      <ul>
        <li>Voting rights must be granted only to schemes, vendors, and
          labs. One vote per organization (not one per representative).<br>
        </li>
        <ul>
          <li>Note: Or at least I think so. But this does bring into
            question "what are the relevant stakeholders?". We seem to
            ignore end customers. Although schemes may represent their
            respective government customers, that representation does
            not extend to enterprise and other customers. What about
            consultants? What about academics?<br>
          </li>
          <li>Note: This whole thing gets very tricky. Should all be
            counted equally? If so, vendors likely always outnumber all
            other stakeholder roles. Maybe that is OK, because vendors
            have a vested interest in keeping all other stakeholders
            reasonably happy. Schemes may insist on the ability to
            override group votes. Labs may feel structurally
            disadvantaged. Or should each stakeholder group vote among
            themselves and then decisions are made according to the
            (three?) stakeholder votes?</li>
          <li>Note: If schemes insist on being able to override a group
            vote, then I suggest that such an action be the result of a
            CCDB majority vote on the issue. That should slow it down
            and help ensure that schemes don't run amok.<br>
          </li>
        </ul>
      </ul>
      <li>Transparency</li>
      <ul>
        <li>All artifacts such as mailing list archives, draft
          documents, meeting minutes, and action items, must be open to
          all members.</li>
        <li>The TC should consider making drafts and minutes accessible
          to the pubic.<br>
        </li>
      </ul>
      <li>PP evaluation</li>
      <ul>
        <li>PPs must be formally evaluated by a lab and overseen by a
          scheme before being made available for conforming product
          evaluations.<br>
        </li>
        <li>PPs should be evaluated by a lab and scheme that is selected
          based on competitive bid.</li>
        <ul>
          <li>Note: Maybe vendors are the only ones who vote on this.</li>
          <li>Note: I don't mean to imply either that (1) the lowest bid
            is always accepted or (2) that "we'll do it for free" is
            necessarily rejected. The point is that we want labs to be
            committed to perform the work in a timely and responsive
            manner, which (based on what I've heard in some of the TCs)
            isn't always the case with volunteer PP writing/evaluation
            efforts.<br>
          </li>
        </ul>
      </ul>
      <li>Ownership of work product</li>
      <ul>
        <li>The TC must hold copyright to the PPs, SDs, or any other
          work products.</li>
        <li>The copyright must permit free licensing for specific
          derivative works (e.g. STs, evaluation artifacts, etc.)..<br>
        </li>
      </ul>
      <li>Legal protection</li>
      <ul>
        <li>TC members must be given some protection from anti-trust
          accusations or similar legal actions.</li>
        <li>Each meeting must be preambled by a standard statement about
          inappropriate topics.<br>
        </li>
      </ul>
      <li>Intellectual property</li>
      <ul>
        <li>The TC must have a policy about disclosure of essential
          patents.</li>
        <li>Each meeting must be preambled by a standard statement about
          such disclosure.</li>
      </ul>
      <li>Sustainability</li>
      <ul>
        <li>The TC must be created with the capability and intent to
          remain in operation indefinitely so that questions can be
          answered, interpretations made, and PPs and SDs reaffirmed or
          revised as needed.<br>
        </li>
        <li>The TC should have a plan to turn its copyright works over
          to a suitable entity (the CCDB? is the CCDB a legal entity?)
          in the event of its disbanding.<br>
        </li>
      </ul>
    </ul>
    One final note: It would be ideal if one entity could be created
    that could be used as the home for multiple TCs. Perhaps the best
    way would be to establish one TC and after demonstrating that it
    works pretty well, open it up to other TCs. The benefits of having
    one entity for multiple TCs include:<br>
    <ul>
      <li>One membership (and one membership fee) to deal with.</li>
      <li>Consistent policies and procedures, and infrastructure.</li>
      <li>Perhaps most importantly, the ability to collaborate on
        Supporting Documents that can be used by multiple TCs.<br>
      </li>
    </ul>
    <pre class="moz-signature" cols="76">-- 
Regards,
Brian Smithson
PMP, CSM, CISSP, CISA, ISO 27000 PA
Security Research, Planning
Advanced Customer Technologies
Ricoh Americas Corporation
<a class="moz-txt-link-abbreviated" href="mailto:bsmithson@ricohsv.com">bsmithson@ricohsv.com</a>
(408)346-4435</pre>
  <br />-- 
<br />This message has been scanned for viruses and
<br />dangerous content by
<a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
<br />believed to be clean.
</body>
</html>