[VOIPSA Best Practices] Best Practices document structure set -next question: are these the appropriate areas?

[dan_york at Mitel.com]

Nhut,

(Sigh) Yes, you're right.  We probably need a Section 9 called "Emerging 
Areas of Concern" or something like that[1] into which we lump SPIT and 
other miscellaneous things that don't yet have solid best practices 
(because they're not yet solid threats, IMHO) if only so that we can avoid 
the inevitable questions "Why is it that in your entire Best Practices 
document you don't mention SPIT?  How are we to guard against it?" 

Jozef,

- I don't know where fail-over fits. Section 8, in *my* mind (but I'm just 
one contributor) was about all the physical layer stuff that many of us 
network geeks generally try to ignore such as backup power, physical 
security, etc.  I was thinking of it from the "availability" point-of-view 
in that if you lose power and don't have your IP-PBX *and* network 
switches powered by a UPS, your phones are nice pretty bricks.  And you 
should have them in locked rooms, etc.  I don't know that we'll have all 
that many Best Practices in this area.

As to fail-over, I'm not sure... is it in Section 8?  Or is it in call 
control?  I'm not sure on that one... any other opinions?

- Yes, caller ID spoofing is something to be addressed.  Probably in Call 
Control? (Eric Chen, now's probably a good time to weigh in before we 
assign everything to you! :-)    As for ENUM, there's probably a large 
debate on that one, but as we write the best practice around caller 
identification the debate can be waged then.

- QoS - Yes, there is definitely a balancing act between quality and 
security... although I'm not entirely sure how we create that as a best 
practice.  Would the best practice be something like "Install and use 
quality monitoring equipment" - somewhat along the lines of what Gary was 
suggesting earlier?

Love all these comments... keep on sending them in... this is *your* 
document as much as it is mine or anyone elses.  Let's make sure it's 
right.

Thanks,
Dan

[1] Or the section can be called "Issues Related To VoIP Security That Are 
Over-Hyped By The Media Because They Get Attention" (and yes, I know there 
are probably several members of the media subscribed to this list)






"Nhut Nguyen" <nnguyen at sta.samsung.com>
01/19/2007 12:35 PM
 
        To:     "Jozef Janitor" <jozjan at cnl.tuke.sk>, 
<dan_york at Mitel.com>, <bestpractices at voipsa.org>
        cc: 
        Subject:        RE: [VOIPSA Best Practices] Best Practices 
document structure set -next question: are these the appropriate areas?


Hi All,
 
Great discussion! 
 
Regarding SPIT I am not sure if the industry has any good practices yet. I 
believe this problem is emerging but solutions are still in the research 
stage. However, it may be a good idea to have a stub or a place holder to 
document emerging practices like these, or those that address security 
issues of presence information, for example!
 
Cheers,

Nhut
 

From: bestpractices-bounces at voipsa.org 
[mailto:bestpractices-bounces at voipsa.org] On Behalf Of Jozef Janitor
Sent: Friday, January 19, 2007 11:23 AM
To: dan_york at Mitel.com; bestpractices at voipsa.org
Subject: Re: [VOIPSA Best Practices] Best Practices document structure set 
-next question: are these the appropriate areas?
 
Does the point #8 describe also the fail-over procedures? So if my primary 
call controller broke down then the second call controller will 
automatically handle the active calls? This may involve some clustering 
techniques.
 
Also important part of voip security is the credibility of an incoming 
calling number (callid). Because in the PSTN network normally I can’t 
change my callid, but in the VoIP it’s usually not a big problem. Maybe 
this problem could be handled with ENUM.
 
QoS – this is very important when we are going to talk about security in 
voip. We have to consider what level of security do we need because the 
encryption of traffic and other security features are always adding 
additional delay to the transported voice. If the value of this additional 
delay is going to be too high then our call is maybe for 100% secured but 
it’s not pleasant to hear.
 
And SpIT. We know that controlling SPAM in our emails is very difficult . 
But controlling SPAM in VoIP will be even more difficult. So I hope that 
some pages in this document will also cover the possibilities of solving 
the SpIT problem.
 
All the best,
   Jozef Janitor
   www.cnl.tuke.sk
 
 
 
From: bestpractices-bounces at voipsa.org 
[mailto:bestpractices-bounces at voipsa.org] On Behalf Of dan_york at Mitel.com
Sent: Friday, January 19, 2007 11:58 AM
To: bestpractices at voipsa.org
Subject: [VOIPSA Best Practices] Best Practices document structure set - 
next question: are these the appropriate areas?
 

Best Practices team, 

Thank you to those of you who sent in comments either on the list or 
directly to me.  A special thanks to Eugene Nechamkin who took the time to 
write up a counter-proposal. Outside of his contribution, basically all 
the feedback was for proposal #2, structuring the document around 
functional areas, and so I'm going to say we're going with that. 

Now, the next question - is this list below from the wiki the appropriate 
list of areas for VoIP-related best practices? 

1.        Securing Voice and Media stream 
2.        Securing Call Control 
3.        Securing Management Interfaces and APIs 
4.        Securing PSTN Interfaces and Traditional Telephony Issues (i.e. 
don't forget toll fraud) 
5.        Securing Servers and Operating Systems 
6.        Securing IP Endpoints (ex. sets, softphones, etc.) 
7.        Securing the TCP/IP network (ex. VLANs, 802.1X, wireless, etc.) 
8.        Physical Security, including backups, power, etc. 

Are we missing any major areas?  Should these be modified or tweaked? 

It seems to me to be a complete list, but then again, I wrote it, so of 
course it would.  Any feedback is welcome. 

Regards,
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://voipsa.org/pipermail/bestpractices_voipsa.org/attachments/20070119/9cda07cd/attachment.htm>