RE: VoIP Assessment

["lyal.collins" <lyal.collins () key2it com au>]

I'm not sure IDS/IDP will adequately address all availability issues, a
critical element for phone services which are the emergency lifeline of almost
every company.

Lyal.

> Bob -
>
> *If this mail thread is picked up by CBS Radio, Discovery Channel or 
> CNN, you can take all the credit* :)
>
> As the various entities have reported, that combining voice with data 
> is tricky, some early questions to ask before discussing encrypting 
> sessions between end points, gateways and media servers is 1) The 
> capability of the existing network to provide VoIP Calls and the 
> quality of the calls under different network situations.  Most 
> organizations may outsource this to a number of various VoIP hardware 
> or software providers by measuring simulated VoIP traffic and 
> calculating MOS and QOS. The blanket statement that "VoIP is not 
> secure" can be supported  by general security recommendations that 
> have been published by various sources :
> 1) Encrypt VoIP Traffic over a VPN
> 2) Firewalls should be properly configured and validate that firewall 
> vendors have support for SIP and H.323
> 3) Segmentation of voice and data traffic by utilizing VLAN network 
> configurations
> 4) Implement proxy servers in front of firewalls to process incoming 
> and outgoing voice data and
> 5) Validate that server-based IP PBXs are secure
> 6) Ensure that your virus software is up to date
> 7) Implement IDS/IPS solutions to protect against Denial of Service Attacks.
>
> According to the whitepaper published by 
> http://csrc.nist.gov/publications/nistpubs/800-58/SP800-58-final.pdf: 
> " Because of the integration fo voice and data in a single network, 
> establishing a secure VoIP and data network is a complex process that 
> requires greater effort that that required for data-only networks."
>
> Validating whether a particular VoIP solution is secure is very 
> complex, and is not solved by conducting a network security 
> assessment to validate whether the underlying operating system of a 
> media gateway has implemented iptables/ipfilt correctly or if IP 
> phones are susceptible to trivial DOS attacks. Developing ways 
> of  some of the security features inherently lacking in VoIP 
> solutions is just beginning for some vendors, others are scrambling 
> to present their business plans to venture capitalists who would like 
> to capitalize on the fear of organizations, and some groups 
> attempting to jump start a security consulting practice focusing on 
> VoIP security.
>
> At 11:17 AM 7/21/2005, Bob Bell (rtbell) wrote:
> > Mark -
> >
> > My point is that IP Telephony within an enterprise can be secure. There
> > are many things which can be done (such as strong authentication of the
> > endpoints [both the call control agent and the communications
> > endpoint)in conjunction with encrypted and authenticated signaling and
> > media flows, control of provisioning information and images in such a
> > manner that the probability of corruption or modification is extremely
> > low, etc. The blanket statement that "VoIP is not secure" is extremely
> > misleading. If you apply no safeguards to the system (note I am
> > indicating a system level protection) then I would agree with you that,
> > just like file transfers or database access or any of the other
> > applications that exist on a network, it is not secure. If on the other
> > hand, reasonable measures are taken (and there are commercial products
> > that do take them) then the level of security is commenserate with the
> > level of risk.
> >
> > There are a large number of organizations today who are getting a great
> > deal of press coverage by claiming that "the sky is falling" when they
> > are making assumptions that are simply not true. One of the ones that
> > really gets to me is that if you do IP Telephony, you must admit into
> > your network directly any attempted VoIP calls that come at you by
> > opening holes in the perimeter fire walls to admit the traffic. First of
> > all, that is not realistic. We do not do that for web access, nor email
> > access nor any other form of access, why in the world would we do it for
> > voice. It will go through a gateway type device on a DMZ so that the
> > messaging can truly be validated and verified and so that the external
> > party does not have access to information that the corporation deems
> > confidential. Secondly, if it is a remote worker, then the connection
> > will involve a VPN link and so will not be admitted unchecked either.
> > Just because the standards groups envisioned a totally uncontrolled
> > environment, there is nothing that required enterprises (or residential
> > users for that matter) to simply close their eyes and say "cut here".
> >
> > I would agree that there are some "security" consultants that may not be
> > either as complete and accurate as they should be in this area. But that
> > is true of all consultants and all areas. We should not blindly reject
> > as "unprotectable" or "unsecurable" a system that has been demonstrated
> > to be securable.
> >
> > We, the security forces, need to assess the risks and remediation
> > methods to determine both effectiveness and functionality. We must make
> > IPT or VoIP into a viable technology with the protections that are
> > required. We cannot simply assert that there is no hope, because there
> > is.
> >
> > Bob
> >
> > > -----Original Message-----
> > > From: Mark Teicher [mailto:mht3 () earthlink net]
> > > Sent: Wednesday, July 20, 2005 20:24
> > > To: Bob Bell (rtbell)
> > > Cc: intel96; pen-test () securityfocus com
> > > Subject: RE: VoIP Assessment
> > >
> > > Fundamentally, VoIP is not secure, as originally stated, It
> > > depends on what an organization is attempting to validate.
> > > Network security consulting practices will attempt to dazzle
> > > an organization with their "VoIP assessment or VoIP Readiness
> > > services" .  Some concentrate more on VoIP network readiness
> > > and propose bandwidth analysis utilizing tools that either
> > > home grown or commercial.  This may provide some insight on
> > > jitter, latency and other such issues when implementing or
> > > migrating to a VoIP infrastructure.  Discussion of security
> > > issues arise when "former security investigators" or "Ph D"
> > > types get involved in the discussion and start rattling off
> > > statements "As telephone communications move to the IP world,
> > > it will become increasingly easier to intercept and monitor
> > > telephone calls by anyone."  and "How businesses handle
> > > threats to their
> > > converged network will be crucial to their success."   Great buzzword
> > > statements, but they miss the questions that an organization
> > > may have r egarding the underlying security of VoIP and the
> > > various aspects of enabling options that allow for
> > > availability and ease of use for end users.
> > >
> > >
> > >
> > >
> > > At 11:24 AM 7/20/2005, Bob Bell \(rtbell\) wrote:
> > > > Mark, Intel96 -
> > > >
> > > > There are a lot of conflicting opinions floating around as to the
> > > > security of VoIP systems. One of the things that you need to do is
> > > > establish whether you are dealing with a bounded system, (i.e. an
> > > > enterprise PBX replacement) or an unbounded one (i.e. SKYPE) as they
> > > > have considerable differences in both their vulnerability and the
> > > > resources available to deal with issues. Secondly, security
> > > of VoIP is
> > > > not a single dimensional problem. Many of the issues of
> > > protecting VoIP
> > > > occur a layers far below the application layer which is where VoIP
> > > > lives. So, you need to examine the issue from a systems approach not
> > > > simply a point solution for VoIP. Finally, there is a great
> > > deal more
> > > > to providing SYSTEMIC protection beyond simply protecting
> > > the protocol.
> > > > This includes things like the provisioning of the endpoints, the
> > > > control of and validation of the images contained in the
> > > endpoints, the
> > > > authentication and authorization schemes for the endpoints
> > > and users,
> > > > etc. If I can be of help, please feel free to contact me.
> > > >
> > > > Bob
> > > >
> > > > IPCBU Security Architect
> > > > Cisco Systems, Inc.
> > > > 576 S. Brentwood Ln.
> > > > Bountiful, UT 84010
> > > > 801-294-3034 (v)
> > > > 801-294-3023 (f)
> > > > 801-971-4200 (c)
> > > > rtbell () cisco com
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Mark Teicher [mailto:mht3 () earthlink net]
> > > > > Sent: Tuesday, July 19, 2005 16:40
> > > > > To: intel96
> > > > > Cc: pen-test () securityfocus com
> > > > > Subject: Re: VoIP Assessment
> > > > >
> > > > > What specific items have you been tasked to validate?
> > > > > Could be as simple as :
> > > > >          Are the components VoIP capable?
> > > > >                  If so, then what protocols have been implemented
> > > > > (Y/N)
> > > > >                     If x protocol, if implemented correctly (i.e
> > > > > when enabled, does it process the traffic correctly (Y/N)
> > > > >                           If x protocol, if implemented correctly
> > > > > (i.e. when x protocol is disabled, does it block VoIP traffic
> > > > > inbound/outbound? (Y/N)
> > > > >
> > > > > and so and so on
> > > > >
> > > > > Lots of those "security" type experts will overstate the
> > > obvious and
> > > > > start rattling off big words like MITM attacks, Resource
> > > exhaustion,
> > > > > H.323 attacks, SIP Overflow attacks, etc, etc, but IMHO, simplify
> > > > > what the tasks are, and break those tasks into simple
> > > steps that any
> > > > > former senior security consultant can do by utilizing a checklist
> > > > > approach, otherwise one gets into the battle with the "puffed out
> > > > > chest security wannabes "
> > > > >
> > > > > /m
> > > > > At 01:40 PM 7/19/2005, intel96 wrote:
> > > > > > I have been asked to look at the security of a VoIP
> > > > > architecture.  Has
> > > > > > anyone conducted a security assessment against VoIP or the
> > > > > components
> > > > > > that make up the architecture?
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Intel96



--