On Wed, Jul 10, 2019 at 11:56 PM Sean Donelan <sean@donelan.com> wrote:
On Tue, 9 Jul 2019, Sean Donelan wrote:
The agenda looks like lots of happy, happy talk from industry representatives.
In advance of the SHAKEN/STIR robocall summit, AT&T has issued a press release announcing plans to automatically block robocalls for its customers.
https://about.att.com/story/2019/att_call_protect.html
Automatic Blocking of Fraud Calls Coming to Millions of AT&T Customers AT&T* will add automatic fraud blocking and suspected spam-call alerts to millions of AT&T consumer lines at no charge.
oh goodie! So, not being a bell shaped headed person... a question: The calling path and data available inside the phone network smells (to me) like: ingress trunk + ANI + CallerID + outgoing trunk of destination ds0/handset There seem like a bunch of pretty simple 'correlations' one could make, that actually look a heck of a lot like 'netflow/log analysis for ddos detection': o is this trunk sourcing calls to 'too many' of my subs in period-of-time-X o is this trunk sourcing calls from a low distribution of ANI but a different distribution of CallerID o is this trunk sourcing calls from unmatched (as a percent of total) ANI/CallerID I would think you could make similar correlations across the destinations on your phone-network: o Is there one ANI or CallerID talking to 'all' (a bunch, more than X of type Y customer end point) of my endpoints? o are there implausible callerid being used? (lots of 'NPA-NXX matches destination, yet from a very different geography?) I imagine that with the number of calls here, this is just a splunk correlation away from successful identification and then disabling of these nuisance calls... I imagine this doesn't need 'shaken' nor 'stir', but DOES take: "a whiff of a care" on the part of the carrier(s), right? Maybe they don't actually care about this problem until they are 'forced' to care about it by their regulating body? 'shaken' and 'stir' may not do anything at all useful for the problem, but they do make it appear that the carriers care about the problem... I'm certain that they know there are problems. The 5 items above can't be 'new and novel' concepts ... since this is basically 'logs analysis' that any security engineer worth their salt does as a matter of course daily, right? -chris