<br><font size=2 face="sans-serif">Best Practices team,</font>
<br><font size=2 face="sans-serif">----</font>
<br><font size=2 face="sans-serif">WARNING -> Long msg ahead.  Probably
not terribly fun to read on a Blackberry or other similar device.</font>
<br><font size=2 face="sans-serif">----</font>
<br>
<br><font size=2 face="sans-serif">Okay, so with a document structure in
hand, we are looking for a few good section leaders!  Currently, three
people have stepped forward:  Eric Chen, Jerry Mangiarelli and Peter
Kuebler.  Eric called #2, "Call Control" and Jerry said
he'll do either #5, "servers/o/s"  or #7, "TCP/IP network".
 Peter has not yet indicated his choice.</font>
<br>
<br>
<br><font size=2 face="sans-serif">1.        </font><font size=3>Securing
Voice and Media stream </font>
<br><font size=3>             
  - not yet assigned</font>
<br><font size=2 face="sans-serif">2.        </font><font size=3>Securing
Call Control         </font>
<br><font size=3>             
  - Eric Chen</font>
<br><font size=2 face="sans-serif">3.        </font><font size=3>Securing
Management Interfaces and APIs </font>
<br><font size=3>             
  - not yet assigned</font>
<br><font size=2 face="sans-serif">4.        </font><font size=3>Securing
PSTN Interfaces and Traditional Telephony Issues (i.e. don't forget toll
fraud) </font>
<br><font size=3>             
  - not yet assigned</font>
<br><font size=2 face="sans-serif">5.        </font><font size=3>Securing
Servers and Operating Systems </font>
<br><font size=3>             
  - Jerry Mangiarelli is open to this or #7</font>
<br><font size=2 face="sans-serif">6.        </font><font size=3>Securing
IP Endpoints (ex. sets, softphones, etc.) </font>
<br><font size=3>             
  - not yet assigned</font>
<br><font size=2 face="sans-serif">7.        </font><font size=3>Securing
the TCP/IP network (ex. VLANs, 802.1X, wireless, etc.) </font>
<br><font size=3>             
  - Jerry Mangiarelli is open to this or #5</font>
<br><font size=2 face="sans-serif">8.        </font><font size=3>Physical
Security, including backups, power, etc. </font>
<br><font size=3>             
  - not yet assigned</font>
<br>
<br><font size=2 face="sans-serif">So we're now looking for 5 more people
to step up and volunteer as Section Leaders.  Note that some sections
may have only a few best practices and others may have a lot. </font>
<br>
<br><font size=2 face="sans-serif">So what does it mean to be a "Section
Leader"?</font>
<br>
<br><font size=2 face="sans-serif">On http://wiki.voipsa.org/tiki-index.php?page=Volunteer+Opportunities%2FTeam+Structure
I wrote this:</font>
<br><font size=2 face="sans-serif">----</font>
<br><font size=2 face="sans-serif">If we can identify <i>one</i> volunteer
who agrees to be responsible for <i>each</i> section, then we basically
have a "core team" that can lead the effort. I would <i>NOT</i>
expect a "section leader" to write the text, but rather to help
<i>find</i> people to write pieces and ensure that the section is being
completed - and then perhaps most importantly dealing with comments that
reviewers may leave. These folks also being able to say to everyone else
when help is needed or when there's a conflict that has to be sorted out.
<br>
<br>
To be a section leader, I don't think you necessarily have to be a subject
matter expert on that particular section, although it may certainly be
helpful. It is probably more important to be a good communicator and not
tell people they are flaming idiots and scare any volunteers away. (No
worries, any such project leaders will be ejected! :-) </font>
<br><font size=2 face="sans-serif">----</font>
<br>
<br><font size=2 face="sans-serif">One other aspect - the section leaders
should either be okay with working in a wiki website or be willing to learn.
 (It's not difficult.)</font>
<br>
<br>
<br><font size=2 face="sans-serif">Here's how I see it working.  Let's
take the section on voice encryption.  There's going to be some basic
best practices statements like:</font>
<br>
<br><font size=2 face="sans-serif">1. All voice and media streams should
be encrypted.</font>
<br><font size=2 face="sans-serif">2. Voice encryption should be performed
with Secure RTP (SRTP) using at least 128-bit AES encryption.</font>
<br><font size=2 face="sans-serif">3. Secure traversal of a firewall should
be accomplished via an application-layer gateway.</font>
<br>
<br><font size=2 face="sans-serif">The section leader's first task is to
come up with some statements like that through things like:</font>
<br><font size=2 face="sans-serif">  - Putting some basic statements
up on their section wiki page (either that they know or have gleaned from
other best practices documents)</font>
<br><font size=2 face="sans-serif">  - Asking for input from this
mailing list.</font>
<br><font size=2 face="sans-serif">  - Reading comments left on the
wiki pages</font>
<br>
<br><font size=2 face="sans-serif">This last point is important.  Section
leaders, editors and other volunteers will be given the ability to edit
the wiki and make changes to the actual pages.  Everyone else, including
random people reading the pages, will have the ability to *comment* on
the page through the comments tab.  The section leader will be responsible
for monitoring those comments, incorporating changes/suggestions/etc.</font>
<br>
<br><font size=2 face="sans-serif">The second task of the section leader
is to forge agreement around whether those statements are complete.  Should
they be merged?  Should they be separated?  Are there other points?
 Again, through this mailing list and/or comments to the wiki and
potentially through private dialog as well.</font>
<br>
<br><font size=2 face="sans-serif">For instance, in my example, should
the first two bullets be merged into "All voice and media streams
should be encrypted with Secure RTP (SRTP) using at least 128-bit AES encryption"?
 Maybe, maybe not.  That's for the section leader to help sort
out.</font>
<br>
<br><font size=2 face="sans-serif">In my example, is the third statement
true?  (I can already feel a couple of firewall vendors I know getting
elevated blood pressure. :-)  Maybe the statement holds.  Maybe
it needs to be modified. Maybe it needs to be dropped. Those are the type
of conversations the section leader needs to engage in.</font>
<br>
<br><font size=2 face="sans-serif">The section leader also needs to escalate
an issue to the larger list if we should have any practice that gets mired
in conflict.  (ex. "Best Practices members, we're in a bit of
deadlock in the wiki comments about whether this statement on application-layer
gateways should even be in here.  Can any of you who have an opinion
please weigh in?  Thanks, <Section 1 leader>")</font>
<br>
<br><font size=2 face="sans-serif">The final task of the section leader
will be to facilitate the creation of the documentation around the individual
best practice statements once the general statements have been agreed upon.
 Up on http://wiki.voipsa.org/tiki-index.php?page=Development+Process
I suggested that we needed to have this information for each best practice:</font>
<br>
<ul>
<li><font size=3>Title </font>
<li><font size=3>One-line summary (if title is not descriptive enough.)
</font>
<li><font size=3>Brief description of best practice. Is it a process? a
technology? how is it commonly implemented? </font>
<li><font size=3>Cross-reference to Threat Taxonomy - which treats in the
TT are eliminated, mitigated or reduced by this best practice? (ex. encryption
x-ref'd to eavesdropping) </font>
<li><font size=3>Which common security test/attack tools would this best
practice protect against? or reduce the effectiveness of? (ex. encryption
protects against Wireshark RTP re-assembly) </font>
<li><font size=3>List of references - what "neutral" sources
of information are available about this practice? (ex. Wikipedia articles,
government reports, etc.) </font></ul>
<br><font size=2 face="sans-serif">The "brief description" might
be only a few sentences or it might be several paragraphs (or more).  I'm
sure it will vary.  We need to gather it.  Whether the section
leader writes it or finds the links themselves, or whether he/she finds
other people to help... the key is that they are taking responsibility
for those areas.</font>
<br>
<br><font size=2 face="sans-serif">I'm sure there will be comments on the
text, suggestions for other tools/sources/etc. and those comments/suggestions
need to be addressed and incorporated where appropriate.</font>
<br>
<br><font size=2 face="sans-serif">That's how I see it working.  Depending
up the section, it may or may not be a large amount of work... some sections
may only have a few best practice statements and they will all be non-controversial.
 Others may have many and/or may have controversial statements.</font>
<br>
<br>
<br><font size=2 face="sans-serif">So what do you get in return for volunteering
as a section leader?  Well, this large computer manufacturer will
be sending you a new laptop equipped with the latest.... er... no.  VOIPSA
will write you a large check in the sum of... well... what do we get if
divide the VOIPSA budget for the Best Practices project among all section
leaders? Since that budget is effectively $0... I guess that's out.</font>
<br>
<br><font size=2 face="sans-serif">In truth, you'll get the satisfaction
of knowing you will be helping a whole lot of people out there make their
systems more secure.  You will also be mentioned prominently in the
credits of the document which may lead to more recognition in your industry
or in the security industry in general. (see pages 5 and 6 of the Threat
Taxonomy for an example - http://www.voipsa.org/Activities/VOIPSA_Threat_Taxonomy_0.1.pdf
)  This may or may not be helpful for career advancement.</font>
<br>
<br><font size=2 face="sans-serif">I think you'll probably learn a good
bit (even if only how to edit in TikiWiki!) and we should have some fun
along the way.</font>
<br>
<br><font size=2 face="sans-serif">So... who's in?     Looking
for 5 more folks willing to put in some time over the next couple of months.
 Please let me know if you are interested (and if so, in which of
the unassigned sections).</font>
<br>
<br><font size=2 face="sans-serif">Thanks - and have a great weekend,</font>
<br><font size=2 face="sans-serif">Dan</font>
<br>
<br><font size=2 face="sans-serif">-- <br>
Dan York, CISSP<br>
Dir of IP Technology, Office of the CTO<br>
Mitel Corp.     http://www.mitel.com<br>
dan_york@mitel.com +1-613-592-2122<br>
PGP key (F7E3C3B4) available for <br>
secure communication<br>
<br>
</font>