[VOIPSEC] Who the heck needs security anyway...

[Ari Takanen]

Hi Jason,

I am not disagreeing with you, I just wanted to clarify that the
viewpoints we have are completely different.

On Tue, Apr 20, 2010 at 10:26:38AM -0500, Jason Ostrom wrote:
> "Security" is different for everyone.  For some people, security is
> being allowed to have the dancing pigs and flying bears on their
> screen.  To others like the "VoIP Engineers", it is being able do
> QA, SDLC, and find software bugs, to help improve the reliability of
> their VoIP solution.

Exactly. It works the same way everywhere. Most VoIP engineers
(hopefully) understand the threats in VoIP, and the counter-measures
needed. Most VoIP security books cover that topic extensively, listing
both threats, attacks, vulnerabilities and countermeasures. It is easy
to build a safe VoIP environment. Still, there are end-users who do
not choose to build a secure VoIP network, and need constant reminding
that the decision comes with risks.

Comparing that to banks, no European bank (hopefully) would be crazy
enough to have only username/password authentication for banking
customers. The risk is just too high. Still, many banks in the world
are even today using that. It is an informed decision. Some love the
thrill of minimal risk prevention, maximum profit. Others prefer to
build fortresses.

Tools are often the best solution, but they will never replace all
manual work. Tools aim to find majority of the flaws quickly, before
time-consuming and expensive security expertise is needed. Tools come
in two categories:

1) Reactive: Nessus and SiVuS and the like. These are those health
check tools, desperately needed for those end users walking the thin
line of threats and informed risk decisions. You choose not to install
the latest Cisco patches? Fine. No authentication needed? Ok. Digest
authentication is enough? Why not. If you need this, I believe Jason
has the solution. ;)

2) Proactive: PROTOS and tens of others. These are the tools that
catch new and unique zero day weaknesses even before the vendors know
about them. When you are certain you have all security features in
place and the latest software versions in place, this is what you look
for in security testing. This is our playground. ;)
  
> It all depends on whether you are testing from a Voice VLAN port or
> over the public Internet, and what VoIP / UC specific attacks are
> most at risk.

Sorry but no it doesn't. It is equally easy to attack a VoIP device
behind VLAN or even 3G/4G/IMS, as something directly connected to
Internet.

> Because we've seen that criminals and real attackers are motivated
> most by financial gain, and vulnerabilities related to toll fraud
> have a high risk, financial impact.

Yes, stealing money is probably more motivating for VoIP criminals
than just pure mischief such as DoS, or installing a botnet.

But for the network owner, this is just basic risk assessment. Compare
the value of someone "toll frauding" e.g. 1 million USD (definitely
possible) against someone DoS:ing the entire telephony service for a
day (or week). If your total revenues in telephony are less than 400
million, then yes you might want to fix the toll frauding issue
first. It is also about which weakness/risk is easier/cheaper to
fix/mitigate? It is really about risk assessment and informed business
decisions. Just like in banks. You have to understand the threats,
risks and weaknesses, so that you can prioritize the countermeasures.

> For example, I was involved in a remote VoIP security test recently,
> in which the customer was suffering financial loss from toll fraud.

The example you presented was reactive elimination of known issues in
software and in VoIP, and then correcting them. Did you prevent toll
fraud? No. Just one instance of it. Very standard practise in
forensics and incident response. Good practise? Definitely! Is it
enough to protect you? No. You will still stay trapped in the
patch&penetrate race, and security companies love that race.

> To me this is how it works with "security testing":

To me it seems you are explaining security auditing/assessment, not
security testing. Audit/assessment verifies the "goodness" of the
deployment. You are auditing the skills of the network engineers and
the administrators. Testing verifies the "goodness" of the
software/service itself.

Best regards,

/Ari

-- 
Check out latest news from Codenomicon: http://www.codenomicon.com/news/
Check out my book on fuzzing: http://www.fuzz-test.com/

-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-
Ari Takanen                   Codenomicon Ltd.
ari.takanen at codenomicon.com   tel: +358-40 50 67678
PGP: http://www.codenomicon.com/codenomicon-key.asc
-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-