Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Endpoint

11/12/2019
01:00 PM
Mark B. Cooper
Mark B. Cooper
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

SHAKEN/STIR: Finally! A Solution to Caller ID Spoofing?

The ubiquitous Caller ID hasn't changed much over the years, but the technology to exploit it has exploded. That may be about to change.

Fraud and abuse in the form of robocalling, and more specifically illegally spoofed calling, is the No. 1 consumer complaint to the Federal Communications Commission (FCC). Robocalls make up nearly half of all phone calls, so frustrated consumers simply don't answer incoming calls and businesses can't get through to customers when they need to reach them.

At the root of the problem is the ease of spoofing caller IDs. Anyone can spoof their outbound Caller ID by using an online service like Spooftel or SpoofCard. These services are meant to protect the caller's number from being displayed and claim they aren't intended for malicious purposes, but the fact that they exist indicates the breadth of the problem.

For cybersecurity professionals, Caller ID spoofing is a particularly pernicious problem. To gain the trust of their intended victim, hackers hide behind a friend, company, or institution associated with their target's information. Typically, they will find a trusted number and spoof it.

Caller identifications are determined during the second ring of a call. In this short period, spoofers use frequency shift keying to alter the binary format of the number, a process that can be automated. Current Caller ID technology was developed without any consideration that it could be used nefariously and hasn't changed much, while the technology to exploit it has exploded.

The FCC Steps in with SHAKEN and STIR
FCC chairman Ajit Pai challenged the telecommunications industry in November 2018 to adopt a caller authentication system to combat this growing nuisance or face regulatory intervention. This has spurred the telecommunications industry to develop a framework of interconnected standards called SHAKEN (Secure Handling of Asserted information using toKENs) and STIR (Secure Telephony Identity Revisited) that defines how telephone service providers should work together to ensure calling numbers have not been spoofed.

As with many secure platforms on the Internet, digital identity certificates that leverage public key infrastructure (PKI) will make it possible to verify that the Caller ID information is accurate and can be trusted. SHAKEN/STIR shifts responsibility for identity verification from the call originator to the originating telephone company routing the call. At a high level, each telephone service provider will obtain its digital certificate from a certificate authority that is trusted by other telephone service providers. The certificate technology enables the called party to verify that the calling number is accurate, as asserted by a trusted source.

As shown in the framework diagram below, telecommunication service providers must implement a certificate management system to create and manage the public and private keys and digital certificates used to sign and verify Caller ID details. The private keys are used by the service provider to sign calls. The public key is then used by other service providers to verify that the signature was actually created by the private key associated with a trusted provider.

Also Applies to Enterprise VoIP
Although SHAKEN is a carrier-centric framework that sets out a standard way to implement STIR on the Internet Protocol-based network-to-network interface (IP-NNI), it will also affect enterprises that have their own Voice over IP (VoIP) infrastructure. In the next several years, such enterprises will be expected to set up call authentication through the SHAKEN/STIR delegation feature. Carriers can delegate authority for telephone numbers assigned to enterprises, making them a participant in the SHAKEN/STIR ecosystem.

For this ecosystem to work, the industry — technology infrastructure, telecommunications, enterprises, and government entities — needs to work together to ensure call identities are universally trusted. As this technology standard evolves and starts to be deployed, security will be required at every level of SHAKEN/STIR implementations. The players involved need to educate themselves on the many places where things can go wrong, including bad policies, lax security controls, and weak operational practices. Bad actors will absolutely try to subvert this security to initiate "validated" calls.

The telecommunications landscape is vast and diverse, with players ranging from massive corporations to virtual telcos that aggregate services and service providers serving niche clients or small geographies. For SHAKEN/STIR to accomplish its goal of re-establishing trust in the phone system, every provider will need to come up to speed on the nuances of setting up a PKI correctly.

Chances are, however, that not every provider will have the necessary expertise in-house but may decide to forge ahead on their own. When that happens, things invariably will go wrong; all it will take is one weakness in a PKI implementation for spoofers to get back in the game. As more telcos implement SHAKEN/STIR, the value on the underground of having a provider's certificate in a compromised state is significant. All of a sudden, robocallers with a validated Caller ID can start making spoofed robocalls again after everyone has started to trust Caller IDs again. There is a large financial incentive for robocallers to identify weaknesses and exploit them for financial viability.

A Long Slog Ahead
Although the FCC wants to accelerate the timeline for SHAKEN/STIR implementations across the industry, the reality is that it's going to take time. Rather than rushing ahead, a far better approach will be to invest the time and resources necessary to ensure that the system is implemented properly and highly secure. Things are moving ahead with the all-important role of Secure Telephone Identity Policy Administrator (STI-PA) being awarded to
iconectiv in May 2019. In this role, iconectiv is responsible for applying and enforcing the rules defined for the SHAKEN/STIR framework.

The certificate policy will be published soon. It will lay out the rules of engagement, but without it there is significant uncertainly. Do you have to have an audit? If so, what does that audit look like? And what does it have to look at? What requirements do organizations have for security? What about availability, background screening, and training?

While these pieces are coming together, I would encourage everyone in the ecosystem to proactively line up the necessary resources and expertise to implement SHAKEN/STIR in the most secure way possible. If in-house know-how is lacking, companies should track down experts who can help get the PKI implemented correctly and address problems such as cloud vs. on-premises deployment and scalability. There's no time to waste: The integrity and trust of the telephony system depends on getting this right.

Related Content:

Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Today's top story: "Account Fraud Harder to Detect as Criminals Move from Bots to 'Sweat Shops."

Mark B. Cooper, President and Founder of PKI Solutions, has been known as "The PKI Guy" since his early days at Microsoft. Mark has deep knowledge and experience in all things public key infrastructure (PKI), including Microsoft Active Directory Certificate Services ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
When It Comes To Security Tools, More Isn't More
Lamont Orange, Chief Information Security Officer at Netskope,  1/11/2021
US Capitol Attack a Wake-up Call for the Integration of Physical & IT Security
Seth Rosenblatt, Contributing Writer,  1/11/2021
IoT Vendor Ubiquiti Suffers Data Breach
Dark Reading Staff 1/11/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
2020: The Year in Security
Download this Tech Digest for a look at the biggest security stories that - so far - have shaped a very strange and stressful year.
Flash Poll
Assessing Cybersecurity Risk in Today's Enterprises
Assessing Cybersecurity Risk in Today's Enterprises
COVID-19 has created a new IT paradigm in the enterprise -- and a new level of cybersecurity risk. This report offers a look at how enterprises are assessing and managing cyber-risk under the new normal.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-3113
PUBLISHED: 2021-01-17
Netsia SEBA+ through 0.16.1 build 70-e669dcd7 allows remote attackers to discover session cookies via a direct /session/list/allActiveSession request. For example, the attacker can discover the admin's cookie if the admin account happens to be logged in when the allActiveSession request occurs, and ...
CVE-2020-25533
PUBLISHED: 2021-01-15
An issue was discovered in Malwarebytes before 4.0 on macOS. A malicious application was able to perform a privileged action within the Malwarebytes launch daemon. The privileged service improperly validated XPC connections by relying on the PID instead of the audit token. An attacker can construct ...
CVE-2021-3162
PUBLISHED: 2021-01-15
Docker Desktop Community before 2.5.0.0 on macOS mishandles certificate checking, leading to local privilege escalation.
CVE-2021-21242
PUBLISHED: 2021-01-15
OneDev is an all-in-one devops platform. In OneDev before version 4.0.3, there is a critical vulnerability which can lead to pre-auth remote code execution. AttachmentUploadServlet deserializes untrusted data from the `Attachment-Support` header. This Servlet does not enforce any authentication or a...
CVE-2021-21245
PUBLISHED: 2021-01-15
OneDev is an all-in-one devops platform. In OneDev before version 4.0.3, AttachmentUploadServlet also saves user controlled data (`request.getInputStream()`) to a user specified location (`request.getHeader("File-Name")`). This issue may lead to arbitrary file upload which can be used to u...