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

[Jason Ostrom]

I do see and understand your viewpoint below, Ari.  Just a couple of 
points for clarification.

Ari Takanen wrote:
> 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. ;)
>   
Can't we be nice and respectful here, eh?  *wink*  As I said before, we 
use all test methods in our security assessments, test cases that would 
be considered both "proactive" and "reactive." 

>> 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.
>   

I think we misunderstood each other.  What I said was that the tests 
used all depend on where you are testing from and what VoIP / UC attacks 
the customer is most concerned to protect against.  I don't make 
assumptions about what security is for everyone because it differs for 
every customer, and assuming that everyone is concerned about say, 
fuzzing attacks (or eavesdropping) would be presumptuous.  You can't 
conduct VoIP Eavesdropping attacks against an RFC1918 non-routable 
subnet over the public Internet, which is to say, there are 
VoIP-specific attacks more applicable to internal networks, and there 
are VoIP-specific attacks that are more applicable to testing remotely.  
So no, it is not equally easy to attack a VoIP device behind a VLAN - 
unless you assume that all attacks are remote IP packet injection 
attacks and you have unfiltered IP reachability to every device.  Again, 
it all depends on where you are sourced from, what UC/VoIP attacks you 
are testing, and what IP address you are testing against. .

>   
>> 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.
>   
Yes, I agree, hallelujah!  In this example, we were reacting to an 
incident.  That was just one example though.  There are many others.  
Some customers are proactive and want to get a security assessment 
performed before an incident.  We had one customer recently who was 
rolling out a new technology (TelePresence) and wanted to understand the 
vulnerabilities.  They were proactive and that should be commended and 
encouraged. 

Actually, yes, we did help protect the customer - for that point in 
time.  That is all a security assessment can be expected to do.  It 
takes a snapshot of the security configuration and architecture.  It was 
reactive but it could have been more proactive had a qualified security 
assessment been performed before it happened.  That's what a security 
assessment is - you take a snapshot view of the vulnerabilities for that 
specific point in time.  After you leave, the configuration could change 
and new vulnerabilities could be introduced in.  Humans make mistakes.  
Change happens.  That is out of your control.  But that's why it is 
recommended to re-test the network on a regular basis.  Look at the 
Moore/Pena toll fraud case.  It was mostly a matter of Security 101 - 
admin interfaces enabled over the public Internet and default passwords 
(from my understanding), and then they could take complete control over 
the devices to re-route calls.  When you say patch and penetrate, I 
think you are referring to software bug testing.  Very important, yes, 
but this wouldn't have saved them in this particular scenario.  Just 
multiple critical vulnerabilities in the configuration, deployment, and 
dial plans of multiple devices that allowed toll fraud through the VoIP 
Gateways and SBCs.

>   
>> 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.
>   
To me, security testing is the process of testing something - the object 
of testing can be anything.  I think it can mean testing software as 
well as testing a deployment.  We have different backgrounds and I can 
see how you would understand the context to mean testing software.  Yes, 
I was referring to "security testing" as performing a security 
assessment.  I don't see testing software and testing a deployment as 
mutually exclusive.  A deployment can include the overall architecture:  
the configuration of each public facing device as well as the software 
services listening on each public facing device.  A security assessment 
includes testing components for both the configuration of the deployment 
as well as testing the software.  Testing software is extremely 
important, I agree with you. Some security consultants can afford the 
nice and expensive fuzzing tools, and some of them have to develop them 
in-house :)  That is great for them.  By the way, when was the last time 
that PROTOS has been updated since it was released?
> Best regards,
>
> /Ari
>
>   
You too.
Jason