Comments
Companies Blindly Believe They've Locked Down Users' Mobile Use
Newest First  |  Oldest First  |  Threaded View
carlm21
50%
50%
carlm21,
User Rank: Apprentice
4/9/2018 | 1:35:04 AM
Re: Pardon me but ......
good one
Joe Stanganelli
50%
50%
Joe Stanganelli,
User Rank: Ninja
11/21/2017 | 7:51:19 AM
Re: Pardon me but ......
A very fair point. That said, the fundamental problem I see is that there is no holistic data-protection design going into this. "Locked down" should not be the way to think about this issue because in this context (the way I see it) we're not talking about locking data down so much as regulating its flow.

To be certain, cybersecurity, data privacy, and compliance all do fall within the grander bucket of "data stewardship," but they also need to be thought of separately. Trying to achieve compliance and privacy goals while wearing a security hat is inevitably going to lead to failure.
Joe Stanganelli
50%
50%
Joe Stanganelli,
User Rank: Ninja
11/19/2017 | 5:12:21 PM
"limited"
Perhaps I need to more carefully review the study itself in context, but it seems that "limited" is the key word here. It's entirely possible that it's not as easy or readily accessible for employees to access these data -- but that they can still do it. So, to be fair, every little bit helps, I would tend to think.
nathandwyer
50%
50%
nathandwyer,
User Rank: Apprentice
11/17/2017 | 1:34:29 AM
Re: Pardon me but ......
Yea...thats really a informative post. I'm new blogger it would be sure helpful information for me i always keep in mind Thanks for sharing.
keith1mathew
100%
0%
keith1mathew,
User Rank: Apprentice
11/15/2017 | 7:18:36 AM
Re: Pardon me but ......
Hello 

Interesting post. Thank you for providing the information. 

Thanks 
REISEN1955
50%
50%
REISEN1955,
User Rank: Ninja
11/14/2017 | 2:26:19 PM
Pardon me but ......
Companies have not even locked down servers and networks.  How can they be so naive as to think that these devices are somehow SECURE???  


What We Talk About When We Talk About Risk
Jack Jones, Chairman, FAIR Institute,  7/11/2018
Ticketmaster Breach Part of Massive Payment Card Hacking Campaign
Jai Vijayan, Freelance writer,  7/10/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-14084
PUBLISHED: 2018-07-16
An issue was discovered in a smart contract implementation for MKCB, an Ethereum token. If the owner sets the value of sellPrice to a large number in setPrices() then the "amount * sellPrice" will cause an integer overflow in sell().
CVE-2018-14085
PUBLISHED: 2018-07-16
An issue was discovered in a smart contract implementation for UserWallet 0x0a7bca9FB7AfF26c6ED8029BB6f0F5D291587c42, an Ethereum token. First, suppose that the owner adds the evil contract address to his sweepers. The evil contract looks like this: contract Exploit { uint public start; function swe...
CVE-2018-14086
PUBLISHED: 2018-07-16
An issue was discovered in a smart contract implementation for SingaporeCoinOrigin (SCO), an Ethereum token. The contract has an integer overflow. If the owner sets the value of sellPrice to a large number in setPrices() then the "amount * sellPrice" will cause an integer overflow in sell(...
CVE-2018-14087
PUBLISHED: 2018-07-16
An issue was discovered in a smart contract implementation for EUC (EUC), an Ethereum token. The contract has an integer overflow. If the owner sets the value of buyPrice to a large number in setPrices() then the "msg.value * buyPrice" will cause an integer overflow in the fallback functio...
CVE-2018-14088
PUBLISHED: 2018-07-16
An issue was discovered in a smart contract implementation for STeX White List (STE(WL)), an Ethereum token. The contract has an integer overflow. If the owner sets the value of amount to a large number then the "amount * 1000000000000000" will cause an integer overflow in withdrawToFounde...