From: lyal.collins (lyal.collins@key2it.com.au)
Date: Fri Jul 22 2005 - 02:45:13 EDT
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
> > > > >
> > >
--
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:54:37 EDT