[VOIPSA Best Practices] Welcome to the VOIPSA Best Practices project... and some weekend reading for you all (if you get this)

Raul Siles raul.siles at gmail.com
Sun Dec 3 20:10:41 CST 2006


Hi Dan,
I'm Raul Siles, an Independent Security Consultant based in Spain and very
much interested (between other security topics ;-)) in VoIP security.

Trying to help with some of your questions:
1. Best Practices references: I agree with most of the docs that have
already been referenced: NIST, Juniper, NEC and Cisco (in fact I was going
to recommend these four) . So, what about referencing the most relevant
books in the field?, such as:

- Practical VoIP Security
by Thomas Porter
Syngress (ISBN: 1597490601)
http://www.syngress.com/catalog/?pid=3720

- Hacking Exposed VoIP: Voice Over IP Security Secrets & Solutions
by David Endler and Mark Collier
McGraw-Hill Professional Publishing (ISBN: 0072263644)
http://www.hackingvoip.com

I know they are not publicly available, but I guess they can be really
useful for anyone trying to find best practices and solutions to secure its
VoIP infrastructure.

2. I vote to use the "SEGMENT INTO FUNCTIONAL(?) AREAS" option, with each
best practice pointing to the corresponding (multiple) Threat Taxonomy
threats (as you've designed).

I specially like the idea of including a field in each best practice to the
tool(s) it protects against. In order to accomplish that, I suggest to
include a specific appendix to the final Best Practices document including
all the tool references used along the paper. I'd also use a field-base tool
entry (as for the best practices) for each tool in this appendix, such as:
- Tool name
- Tool reference (unique, and used along the Best Practices paper).
- Tool description
- Cross-reference to Threat Taxonomy
- Tool reference (URL)
- Latest tool version & date

3. Audience:
- I'd add "VoIP [systems]" to the first item.
- I'd include "network, security and application administrators" to the
third item.

4. Roughly speaking, I agree with the roles. I think that once the projects
starts, we'll have more info to identify new (or remove) roles.

5. Apart from other activities, I volunteer to keep the tool list I
previously mentioned (if it's finally accepted and considered a project
requirement).

6. Questions:

> 1. What is the best structure of the document?

See my previous answer to item 2.

> 2. Can one document cover both enterprise and carrier/service provider
needs?
> 3. If not, do we need to segment the sections?

I vote for a single document, however, I recommend to include a new field
per each best practice to describe if it applies to enterprise,
carrier/service provider or both.
Then, the best practice description should have (at most) three sections
(General, Enterprise & Carrier/Service Provider), where the last two (if
they apply) should detail the specific particularities for these two
environments.

> 4. Given that we are looking to make a *globally-applicable* document, do
we need/want to go into compliance issues such as privacy, E-911/etc.?

Perhaps, an independent document section (or appendix) covering these at the
US, EU, Asia... levels could be the best approach.

> 5. Given that "VoIP" installations today also typically involved other
"unified communications" avenues such as IM and video, how much of that do
we incorporate? Or do we just focus on voice in the first version and
perhaps expand into the other areas in a subsequent version?

I vote for focusing on VoIP in the first version, and once available, expand
further versions into UC (IM, video, E-mail...).

> 6. Do we want to distribute the document under a license such as Creative
Commons?

What are the license used for other VOIPSA projects? BTW, I've used Creative
Commons in the past and is fine for me.
<file:///E:/BACKUP/MyWebPage/www.raulsiles.com/OUTPUT/resources/wifi.html>
Thanks for leading such an interesting project!
--
Raul Siles
GSE
www.raulsiles.com

On 12/2/06, dan_york at mitel.com <dan_york at mitel.com> wrote:
>
>
> VOIPSA Best Practices list,
>
> Welcome to the Best Practices project!   First off, may I just say a huge
> thank you to all of you for wanting to help with this project.  As the list
> admin, I've been watching the subscription notices stream in and we're now
> up around 90 people.  I recognize many of you from the VOIPSEC mailing list,
> from Blue Box podcast listeners, from conferences... but just as many I
> don't recognize... and I look forward to working with you all.
>
> Thank you for your interest in helping.  The continued escalation of news
> reports about VoIP security as well as increased postings to security lists
> only highlights how timely and important this project is.
>
> I may be completely naive, but I honestly don't think this will be an
> enormously long project.  I think that with the collective knowledge we have
> on this list, we can probably lay out most if not all of the required best
> practices relatively quickly.  In fact, I think the thing that may take us
> the longest may be agreeing on how to structure the document. I would like
> to think that this is a project we can complete over the next couple of
> months, realizing that the holidays are in here, of course.  We'll see.
>
> But before I talk about the project, let me just make a couple of points
> about my style and availability, given that many/most of you have not worked
> with me before:
>
> 1. As you'll see below, I've laid out a *suggestion* for how I think
> things should be structured... but please keep in mind that those are
> *suggestions*... I *very* much want to hear your feedback and am definitely
> open to change.
> 2. Please know that I am VERY open to feedback/criticism/suggestions.  I
> have a very thick skin and enough self-confidence that I'm perfectly okay if
> you tell me an idea (or text) of mine is very dumb. (Preferably being polite
> while doing so.)  Please do so...  my objective is to get the best possible
> set of Best Practices that we can- as quickly as we can... I'm not
> interested in having egos (including my own) get in the way.
> 3. Unfortunately I'm getting on a plane Monday afternoon (Dec 4th, Eastern
> US time) heading to London, UK, where I'll be through the end of the week
> (Dec 8th).  There will be periods where my email connectivity will be
> limited and, of course, my Verizon blackberry will not work for email there.
>  (The perils of living in Burlington, Vermont, where GSM coverage is
> limited.)
> It would actually be far better for me to wait a week to launch this
> project, but I very much want to get it moving so that we can get some work
> done before the holiday break.
> I'll be back in the office Dec 11th and don't expect to be travelling
> after that until late January.
>
> So on to the project.  If you go to the main project page in the VOIPSA
> wiki:
>
>   http://wiki.voipsa.org/tiki-index.php?page=BestPracticesHome
>
> you will see that tonight I've created the following pages:
>
> - A proposed development process and document structure:
> http://wiki.voipsa.org/tiki-index.php?page=Development+Process
> - A list of proposed volunteer roles:
> http://wiki.voipsa.org/tiki-index.php?page=Volunteer+Opportunities%2FTeam+Structure
> - Examples of generic best practice statements:
> http://wiki.voipsa.org/tiki-index.php?page=Examples+of+Best+Practices
> - References to other "Best Practices" documents:
> http://wiki.voipsa.org/tiki-index.php?page=Best+Practices+References+
>
> What I would be most interested in feedback on over the next week is the
> following:
>
> 1. Can anyone point to other Best Practices documents that we can add to
> the reference page?  They need to be publicly available (i.e. not
> requiring registration) so that people can see them.
> 2. What do people think about how we should best structure the document?
>  (See my notes on the Development Process page.)
> 3. Do you agree with what I identified as the target audience?
> 4. I've identified about 10 potential volunteer roles... do you agree with
> my thoughts?
> 5. If so,  anyone already willing to step forward and say how they'll
> contribute?
> 6. Any thoughts on the questions I raise at the bottom of the Development
> Process page?
>
> Two final notes:
>
> - Like other VOIPSA lists, this one is set so that, with most mail
> clients, if you just hit Reply your message will go back to only the
> *sender*.  If you want it to go back to the list, you'll need to do "Reply
> to All".
> - This mailing list has a *public* message archive and the wiki is
> entirely public, so please just do realize that everything you send on this
> list or add to the wiki is visible to anyone on the Internet.
>
> With that, I'll again say thank you for joining this project and I look
> forward to working with all of you to make it happen.  If you have any
> questions about all of this, please do feel free to email or call.
>
> Thank you,
> Dan
>
> --
> Dan York, CISSP
> Dir of IP Technology, Office of the CTO
> Mitel Corp.     http://www.mitel.com
> dan_york at mitel.com +1-613-592-2122
> PGP key (F7E3C3B4) available for
> secure communication
>
>
> _______________________________________________
> bestpractices mailing list
> bestpractices at voipsa.org
> http://voipsa.org/mailman/listinfo/bestpractices_voipsa.org
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://voipsa.org/pipermail/bestpractices_voipsa.org/attachments/20061204/26355d13/attachment.htm>


More information about the bestpractices mailing list