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>