Threat Intelligence

6/12/2017
12:34 PM
50%
50%

FTC Issues Advice on Mobile Phone Data Security, Identity Theft

The Federal Trade Commission offers hindsight and foresight on ways to reduce identity theft should your mobile device get stolen.

Smartphones are small and easy to lose or have stolen, but the Federal Trade Commission doesn't believe that the data within the device has to suffer the same fate and is offering up steps to minimize identity theft.

The FTC, for starters, is pointing victims to IdentityTheft.gov, where reports can be filed to law enforcement agencies and a personalized recovery plan is drafted. But in addition to the site, the FTC is offering some before and after tips to smartphone users and BYOD workers.

Before a mobile device is lost or stolen, two-factor authentication should be turned on, as well as iOS' "Find My Phone" or Android's "Find My Device" feature, the FTC advises. The agency also recommends users create a lock on their phone, which would require at least a six-digit password, fingerprint scan, or pattern lock. One of the key suggestions offered up by the FTC is that users need to remember to back up the data on their phones.

But once a phone is stolen or lost, accounts that can be accessed by the phone and have passwords automatically remembered should undergo a password change and those accounts that are tied to the phone should be disconnected from the lost or stolen device, the FTC says. The Commission also recommends watch for any notifications that a new device has attached itself to your email or accounts. Another step the FTC advises users take is to notify the carrier that the device is lost or stolen and it could temporarily or permanently disable the SIM card.

Read more about the FTC's smartphone steps here.

Dark Reading's Quick Hits delivers a brief synopsis and summary of the significance of breaking news events. For more information from the original source of the news item, please follow the link provided in this article. View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Christian Bryant
0%
100%
Christian Bryant,
User Rank: Ninja
6/12/2017 | 1:59:15 PM
Requiring Multi-factor Authentication Configuration
I'm often on the fence with government oversight and involvement in too many facets of technology.  But I'd welcome any future regulations that make end user configuration of multi-factor authentication on mobile devices a requirement such that your phone can not be set up without it.  Some applications are already set up this way as we know, but to establish a blanket Federal requirement for MFA would be a blow to the casual cybercriminal.

I know such regulatory oversight is not acceptable to many, but considering the critical mass cybercrime has taken on, I can't imagine we're far from such regulations anyway.  Better the InfoSec community define the regulations now than allow them to be defined later by ill-qualified agents.
Meet 'Bro': The Best-Kept Secret of Network Security
Greg Bell, CEO, Corelight,  6/14/2018
Four Faces of Fraud: Identity, 'Fake' Identity, Ransomware & Digital
David Shefter, Chief Technology Officer at Ziften Technologies,  6/14/2018
Containerized Apps: An 8-Point Security Checklist
Jai Vijayan, Freelance writer,  6/14/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-5236
PUBLISHED: 2018-06-20
Symantec Endpoint Protection prior to 14 RU1 MP1 or 12.1 RU6 MP10 may be susceptible to a race condition (or race hazard). This type of issue occurs in software where the output is dependent on the sequence or timing of other uncontrollable events.
CVE-2018-5237
PUBLISHED: 2018-06-20
Symantec Endpoint Protection prior to 14 RU1 MP1 or 12.1 RU6 MP10 could be susceptible to a privilege escalation vulnerability, which is a type of issue that allows a user to gain elevated access to resources that are normally protected at lower access levels.
CVE-2018-6211
PUBLISHED: 2018-06-20
On D-Link DIR-620 devices with a certain customized (by ISP) variant of firmware 1.0.3, 1.0.37, 1.3.1, 1.3.3, 1.3.7, 1.4.0, and 2.0.22, OS command injection is possible as a result of incorrect processing of the res_buf parameter to index.cgi.
CVE-2018-6212
PUBLISHED: 2018-06-20
On D-Link DIR-620 devices with a certain customized (by ISP) variant of firmware 1.0.3, 1.0.37, 1.3.1, 1.3.3, 1.3.7, 1.4.0, and 2.0.22, a reflected Cross-Site Scripting (XSS) attack is possible as a result of missed filtration for special characters in the "Search" field and incorrect proc...
CVE-2018-6213
PUBLISHED: 2018-06-20
In the web server on D-Link DIR-620 devices with a certain customized (by ISP) variant of firmware 1.0.3, 1.0.37, 1.3.1, 1.3.3, 1.3.7, 1.4.0, and 2.0.22, there is a hardcoded password of anonymous for the admin account.