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

[Raul Siles]

Dan,
I completely agree with the points you clarified from my previous mail. When
I wrote it, I had in my mind what you exactly described: referencing other
security BP documents for OS and standard applications (not directly related
with VoIP, but required), and covering in our BP document the specific VoIP
shades. This applies to sections #5, #6 and #7, both to OS, applications and
protocols.
Example.- DNS service should be secured according to standard industry best
practices, as noted here [x]. From a secure VoIP perspective, DNS should be
setup in this and that way.

Although my previous mail didn't accurately reflected it, the document scope
must be 100% VoIP related, with external references to general security BP's
when required.

Re fail-over, I think it should be included in the section associated to the
resources where the fail-over solution is applied. That is, if we're
covering fail-over for the call controller (as Jozef suggested), then it
should go into Section #2, Call Control, but if we recommend fail-over for
other types of servers, IMHO, it should go in Sectiom #5, Securing Servers.
If we recommend fail-over for DNS records, then it should go to Section #7,
Securing the TCP/IP net and basic services. And so on and so forth.

I see fail-over as any other security countermeasure/solution, like
encryption, that will be covered in multiple sections: encryption for the
voice and media streams, encryption for call management...

For Qos I suggest to point to other external references more focused on QoS
than in security, although there is an obvious relationship between both. I
think QoS should be pointed out in Section #6, when describing the network
requirements.

I like the idea of Section #9 about cutting-edge and emerging threats (and
related BP's).

Re Eugene comment about covering law implications, take into account this
is/should-be an international document, so if we decide to cover this area,
not only CALEA should be there :-)
--
Raúl Siles
GSE
www.raulsiles.com

On 1/19/07, Jozef Janitor <jozjan at cnl.tuke.sk> wrote:
>
>  Hi Dan,
>
>
>
> Ad fail-over: I think it would fit to section #2, Call Control. I think we
> could describe in that section the fail-over backup solutions. For SIP based
> systems we could talk about the efficiency of multiple DNS SRV records (HA
> vs. HP), and about sharing the registration information from UAs between
> multiple registration servers. So if a UA registers to a SIP server with
> higher priority which after some time broke down, then other servers with
> lower priority will be used for call processing. But then it is important to
> share the registration and call state information between those servers.
>
> BTW: It looks like the Call Control section will be a quite huge section
> :)
>
>
>
> Ad QoS: Designing a secure voip network means the L1-L7 security but it
> also means a well designed a network with QoS. I think the document should
> show the best practices in securing the voip on L1-L7, but it should also
> show some of design paths on QoS – RSVP, CoS, ToS, DSCP, ....
>
>
>
>
>
> Regards,
>
>    Jozef
>
>
>
>
>
> *From:* dan_york at Mitel.com [mailto:dan_york at Mitel.com]
> *Sent:* Friday, January 19, 2007 8:18 PM
> *To:* Nhut Nguyen
> *Cc:* bestpractices at voipsa.org; Jozef Janitor
> *Subject:* RE: [VOIPSA Best Practices] Best Practices document structure
> set -next question: are these the appropriate areas?
>
>
>
>
> 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
>
> _______________________________________________
> 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/20070119/517ae4ef/attachment.htm>