[VOIPSEC] VoIP and Banking Security
Scott Keagy
Scott.Keagy at webex.com
Mon Jun 27 22:12:41 CDT 2005
I spent several years as a product manager responsible for the VoIP security
roadmap of a large vendor. I can tell you quite firmly that enterprises do
indeed demand security features. And customers are willing to quit using a
product because of security shortcomings. Here's a typical scenario I've
seen played out many times:
1) Company pilots a new VoIP system (managed by telecom group),
moving along nicely. Ready to cut the check for the big sale.
2) The INFOSEC group at the company gets wind of the project and
investigates.
3) INFOSEC says, "you can't put that on our network until you fix XYZ"
4) Project is stalled until vendor can meet security requirements
Another viewpoint: a key aspect of security is availability/reliability, and
this clearly is at the top of customer expectations.
I believe the actual urgency of security features on a vendor list may be
low compared to other features, because indeed customers don't ask for such
features as much. But this belies a lack of wisdom on the part of the
vendor. Vendor's typically don't go to a customer and say "which would you
rather have, Feature A or a fix for that glaring security hole you didn't
know about?" It is typically not in a vendor's interest to disseminate info
about internally known security holes or shortcomings (but one must
generally be frank when discussing them when customers ask).
And another point about customer psychology with security features.... They
mostly take it for granted that the thing is secure "enough" if they know to
ask at all. They trust that the vendor won't release it with glaring holes.
However, after a security breach occurs, customers quickly shoot security to
the top of the required list, and as a vendor you had better anticipate this
because you can't react quickly enough to please them and/or keep them. So
security feature prioritization is based more on a set of "what if"
scenarios, probabilities, and costs; ultimately security features are
insurance to protect the product forecast based on customer demand for
features. If you don't do the security features, you lose the other revenue
and your brand. But there is no incremental revenue for security features
(hence the tendency for unwise vendors to put it low on the list).
Regards,
Scott
-----Original Message-----
From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
Behalf Of Thomas Howe
Sent: Monday, June 27, 2005 10:39 AM
To: Brian Rosen
Cc: 'Michael Stauffer'; Voipsec at voipsa.org
Subject: RE: [VOIPSEC] VoIP and Banking Security
Brian,
Working for a vendor myself, I agree with you on one level - there are
adaquate solutions for VoIP carrier and enterprise deployments - our
customers are not hounding us to make them stronger. I would bet that yours
aren't either. Why? Simply put, there's no money they are losing because of
the current level of security - and no money they could make if they had
stronger security.
But, the world of VoIP security is bigger than this. Carriers will lose
money if they are the target of a DOS attack. Carriers will lose money if
some unauthorized carrier piggy backs on their network. I've actually SEEN
that one happen; the money gets big quick.
My personal view is that there is a tipping point, where carriers and
enterprises will have enough money at stake where some "evil doer" (this is
not an endorsement of our President) will try to get some for himself. I
mean, can you name a single time in the history of man where big money was
made, and criminals didn't try to go after some for themselves? This is one
of the times where trying to guess at the right answer like the ITU might be
a bit better then waiting for the bombshell to hit and describe how it got
solved like the IETF. (and this is not an endorsement of the ITU. I'm not a
Geneva fan.)
One other thing - and I can't verify this. If you were SBC, and you were
getting hit up for VoIP extortion money, would you advertise it? I bet you
wouldn't.
Tom
Brian Rosen wrote on 6/24/05, 4:59 PM:
> This is at the heart of what the real big gorilla problem is with VoIP >
and > security:
>
> We have an adequate set of tools available now to provide a service >
that is > secure enough for most personal and commercial applications > >
There is no consumer/customer and therefore carrier, and therefore vendor >
demand for such a secure service.
>
> All of the work on taxonomy and requirements and whatever else we are >
doing > fail to come to terms with the basic problem = no one cares.
>
> If they cared, all the phones and proxies would have the tools we have >
today > implemented. Security is very low on vendor priority lists because
it is > low to non existent on customer priority lists.
>
> Yeah, I know all about PKI problems. There are adequate solutions for >
VoIP > carrier and enterprise deployments reasonably available right now.
>
> Perfect? Not at all; but very, very reasonable security.
>
> THERE IS NO DEMAND
>
> Without it, better tools aren't useful.
>
> Brian
>
> -----Original Message-----
> From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
> Behalf Of Andrew Graydon > Sent: Friday, June 24, 2005 11:34 AM > To:
'Michael Stauffer'; Voipsec at voipsa.org > Subject: RE: [VOIPSEC] VoIP and
Banking Security > > I think there has been a lot of very good discussion
on this point and it > does prove that as an industry we do not have all
the answers. SRTP > should > solve these issues, but in itself is always
possible to circumvent to a > skilled and dedicated hacker. The issue of
putting SRTP on every > stream also > raises issues for implementation,
both CALEA and enterprise/SP > deployments > will have to deal with this
encrypted information.
>
> If we look at the current voice implementations on the phone systems, >
this > level of security is not implemented and it's been working for a
while > ! On > the IP side, while there are provisions for encryption of
email traffic, > widespread usage of such encryption systems is not in use
due to the > implementation and usage issues. For regulatory issues in some
> industries it > is used, but mainly email is sent as the base clear text
system is was > originally setup to do.
>
> We have to be careful as an industry to try to balance the security >
issues > we see from a technical standpoint and the implementation and
usage > issues > from a provider and end user point of view.
>
> These issues will be addressed in the projects starting in the Security
> Requirements Committee and anyone interested in participating should >
look on > the VOIPSA website for information on participation.
>
>
> Andrew
>
>
> _____
>
> Andrew Graydon
>
> Chair Security Requirements Committee > VOIPSA > > agraydon at voipsa.org
> http://www.voipsa.org > -----Original Message----- > From:
Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On > Behalf
Of Michael Stauffer > Sent: June 23, 2005 7:33 AM > To: Voipsec at voipsa.org
> Subject: [VOIPSEC] VoIP and Banking Security > > Al, > > Is being able
to sniff DTMF Digits not in line with your wishes? :) > > Looks like a
RFC 2833 dissector to me, available in Ethereal.
> So can anyone sniff these packets? Well, in a properly configured, >
switched > environment, it's not something that's done without effort, but
a > malicious > agent with sufficient motivation and skill can capture
these, yes. (The > previous discussions from this list on the relative
ease of capturing > in a > switched environment acknowledged). I could be
wrong, but I believe SRTP > would take care of this. Thoughts?
>
> Mike Stauffer
> BAH
> VoIP Security
>
>
>
>
>
>
>
>
>
> Greetings,
>
> New here, and yes, I did check the archives first.
>
> I just finished a session with my bank using the touch pad on my phone.
> When finished I dumped the packets captured during the transaction (using
> ethereal). I was a little dismayed and a lot alarmed to see wherever the
> protocol was RTP EVE that the numbers I pressed on the phone were >
visible in > the info field:
>
> Payload type=RTP Event, DTMF Eight 8
>
> I'm guessing that if I can sniff these packets, so can anyone else.
>
> Anyone have any comments to calm my nerves?
>
> Thanks,
>
> Al
>
>
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>
>
>
>
>
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>
>
>
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>
_______________________________________________
Voipsec mailing list
Voipsec at voipsa.org
http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
More information about the Voipsec
mailing list