ACTION-22 Voice Browser Use Case...

ACTION-22

Here's a story-board version of a use-case... 

Also, this link has a relevant use case:

http://www.cknow.com/news/security/PhoneSpoofingAddedtoPhish.html

>
>       Phone Spoofing Added to Phishing
>
> You're calmly sitting there and the phone rings. You answer and the 
> person on the other end identifies himself (or herself) as the police 
> and says they are investigating a fraud ring in your neighborhood. The 
> caller-ID checks out and they do have some basic information about you 
> so when they ask you to verify other information like your Social 
> Security Number, credit card number, or other detailed information you 
> agree and give it to them.
>
> You've just become the victim of the latest phishing fraud.
>
> With the ready availability of general information and the ability to 
> make the caller-ID system show a fake caller's location, the latest 
> breed of phishers can now use phone spoofing to try to gather more 
> detailed informaiton by making themselves appear like the real thing.
>
> The standard caveats for giving out information still apply even with 
> this newest scam...
>
>     * Never give out any personal information in any form to any
>       unsolicited caller.
>     * If someone does call asking for information, ask them to put the
>       request in writing and also ask for a call-back number. Chances
>       are you'll never hear from the person again, but if you do
>       receive a written request check it out completely before sending
>       anything.
>     * As with phone calls, never respond to any unsolicited request
>       for information that comes in via E-mail; no matter how valid it
>       looks.
>
> //
>

5.2 Call Lure

Alice is a customer of BobBank. Mallet is an attacker attempting to 
obtain Alice's access credential for the BobBank site by impersonating 
BobBank via the phone.

Mallet places an outbound call to Alice (and a hundres of other users).  
The phone number appears to be from a legitimate 800-number service.  
The voice service introduces itself as BobBank and alerts Alice that for 
fraud verification purposes, they need to ask her a series of 
questions.  The call also says "For verification purposes, please enter 
your account number and numeric pin."  For further verification, Mallet 
asks Alice to state her mother's maiden name.  Finally, the system asks 
some non-identifying information such as "Is your checkbook in your 
possession?",  "Please state the date of your last ATM transaction?",  
"Please enter the amount of your last ATM transaction?".  The call 
concludes by saying "Thank you, your account appears to be in good 
standing at this time. Goodbye."

Mallet also provides an 800 number at the beginning of the transaction 
that can be used to call back when it is convenient.  That 800 number is 
managed by Mallet and answers asking the same transactions. 

Alice and BobBank both have assets at risk. Alice's personal information 
has been compromised and her account may also be compromised at this 
point.  In addition to direct losses due to fraud BobBank may suffer 
indirect losses due to the need to reissue account numbers, pins, and 
checkbooks to Alice and increased customer service calls whether or not 
the attack is successful: Alice may insist on doing all her future 
transactions at a local branch at significantly higher cost to the bank. 
Alice may contact customer service to ask about the attack.



Brad Porter wrote:
> Action 22:  Produce Voice Browser use case... is assigned to me. 
>
> I wasn't involved in the discussion at the time this action was 
> generated, so apologies that I didn't know I had an action and I'm 
> going in a little blind on the context for the request.  That said, 
> let me lay out some of the differences I see in the voice web 
> experience from a Desktop browser as they pertain to security.
>
> *Special Considerations for Web Security in a Voice Browser Context
> *
> /Differences/
>
>     * Interaction with a voice browser is often entirely transparent
>       to the end user.  He or she has no idea whether the interaction
>       is with a voice browser or any other automated phone application.
>
>     * Voice browsers typically have no standard chrome whatsoever. 
>       The entire user experience is defined by the application
>       markup.  There is some standard context information provided to
>       the application markup (callerid, dialed number) which can be
>       found in 5.1.4 of the VoiceXML 2.0 specification [1].
>
>     * Voice browsers have no URL bar.  All content must be navigated
>       to via hyperlinking.  Bookmarking would be an
>       application-specific feature and is not built into the browser
>       metaphor. 
>
>     * A highly interconnected voice web is technically feasible, but
>       does not truly exist today.  Applications live in their own
>       space and do not contain links outside of their domain.
>
>     * For latency reasons, Voice browser deployments often make use of
>       greater presentation markup caching and more separation of
>       dynamic data and presentation data.
>
>     * Trust is typically established via the phone number the caller
>       dialed.  That said, there is no real reason you can trust the
>       phone number.  Trust would be established by the credibility of
>       the source of the phone number (corporate website, phonebook,
>       toll-free directory assistance.)  Outbound calls are inherently
>       less trustworthy. 
>
>     * The search engines in this space are 411 services.  411 data is
>       typically maintained by telcos thorugh their whitepages and
>       yellowpages which usually involves a direct relationship with
>       the business or individual.  It is more difficult to publish
>       yourself as a spoof address.
>
>     * The phone network tends to have more centralized control with
>       substantially greater regulatory control and legal precedent. 
>       For instance, the national do-not-call list generally works
>       where attempts to control email spam haven't.
>
>     * The costs of answering a spoofed 800# or placing malicious
>       outbound calls are substantially higher than the cost of
>       publishing a spoof website or generating an email.
>
> /Similarities/
>
>     * Voice browsers run in a different trust zone than the web
>       services and databases.  Billions of calls a year are handled by
>       voice browsers operated by one company on behalf of another
>       company.  These browsers interpret many different companies'
>       voice applications.  As a result a single voice browser may be
>       able to access content and services that the application running
>       on that voice browser is not allowed to access.  As a
>       consequence, all the same sandboxing requirements apply.
>
>     * Protecting user data and preventing cross-session data leaks is
>       equally critical.
>
>     * Voice browsers make heavy use of Ecmascript. 
>
>     * User authentication is still the responsibility of the web site
>       and not the browser.  Cookies are employed.  Authentication
>       techniques differ due to the inability to effectively recognize
>       random  a strings of letters, digits, caps, and punctuation that
>       is typically found in a typed password.  Biometric
>       identification/authentication  (voice prints) are more easily
>       integrated into the user experience, though they are not widely
>       deployed.
>
>
> --Brad
>
> [1] VoiceXML 2.0 Standard Session Variables 
> http://www.w3.org/TR/voicexml20/#dml5.1.4