Slashdot Mirror
Millions of Records Leaked From Huge US Corporate Database (zdnet.com)
Millions of records from a commercial corporate database have been leaked. ZDNet reports: The database, about 52 gigabytes in size, contains just under 33.7 million unique email addresses and other contact information from employees of thousands of companies, representing a large portion of the US corporate population. Dun & Bradstreet, a business services giant, confirmed that it owns the database, which it acquired as part of a 2015 deal to buy NetProspex for $125 million. The purchased database contains dozens of fields, some including personal information such as names, job titles and functions, work email addresses, and phone numbers. Other information includes more generic corporate and publicly sourced data, such as believed office location, the number of employees in the business unit, and other descriptions of the kind of industry the company falls into, such as advertising, legal, media and broadcasting, and telecoms.
$1 penalty per leaked / stolen record, imposed by the FTC/SEC/SSA/CFPB will quickly remedy this problem. As long as the value of private personal information is intangible, the value it will be assigned in companies' risk assessments and capital plans is $0.
But I guess that would be a burdensome regulation under our new regime.
> $1 penalty per leaked / stolen record
The average cost to a company that's breached is already well over $1 per record, so no that doesn't "quickly remedy this problem". It IS slowly getting things fixed. A lot of companies have a Chief Security Officer now, a C-suite executive responsible for security. That wasn't the case ten years ago.
The issue is, the likelihood of a major breach is low (for each conpany). People, including executives, aren't good at reasoning about unlikely events. On the other hand, insurance companies are very good at it. Risk assessment and risk reduction is their business and they've gotten quite good at it. Insurance companies created the fire code, UL labs, etc to reduce the risk of fire. They hold companies responsible for properly mitigating all kinds of risks, as a condition of issuing insurance. The cost of the insurance, which shows up on the balance sheet, is based on the risk-reduction methods that the insured uses. (Just like installing monitored fire and burglary alarms reduces the cost of your homeowners insurance). I think we'll see a major shift in information security when the insurance companies get more involved, requiring companies they insure to follow certain standards.
From http://www.dnb.com/utility-pag...
"Data Security: Dun & Bradstreet applies appropriate technical, physical, and administrative Data security measures to protect Data against unauthorized access and disclosure."
Except when they don't....
Also, (farther down the page): "Dun & Bradstreet does not respond to Do Not Track Signals."
Just cruising through this digital world at 33 1/3 rpm...
If I were a thief, the thing I'd try attacking is the increasing use of federated identity, and hit those targets with everything I had...social engineering, zero-days, finding soft spots where cut-rate consulting firms left the door open, the works. In the new cloudy world of abstracted everything, companies are finding it easier to rely on a few identity providers..."log in using Facebook" and the like. In the Microsoft, Google and Amazon iterations of this (MS account, Azure AD, Google Account, Amazon Identity Management,) companies are using third parties to handle authentication to their resources (at least on the web.) This means that the identities are slowly being consolidated to a few providers on the corporate side. Anyone using Office 365 in an organization likely has their credentials synchronized up to Azure AD, for example, so they can use the web apps like Outlook and Skype.
OAuth and the like set up a very strong environment, but it's still just an identity database under the hood. Even if the provider has no idea what your password is, a hash of it is being stored somewhere...otherwise you wouldn't be able to authenticate. If anyone ever comes up with an easy way to break this, then everyone's going to be in for a round of password changes and free credit monitoring. Getting someone's corporate credentials gives thieves a lot more access than stealing one database.
It's actually quite simple: just avoid storing all of this sort of data to begin with!
Gawd what a stupid suggestion.
It costs money to store this shit (even insecurely). So why do companies do it? Because they believe that the value of the data outweighs the cost of storing it.
So your idiot "just don't do that" suggestion is basically asking companies to walk away from money because. . .why? Why would they do that?
Would criminalizing the storage of certain data be "non-leftist"?
Spoken like a person who doesn't know what Dunn and Bradstreet do. One of their functions is to store this type of data as well as corporate payment records so businesses can lookup a credit score on other businesses. This let's them do things like setup charge accounts quickly.
It has all the flaws of credit reporting agencies plus their strengths. Speed of modern business that the time wasted filling out a credit report, sending it in, hoping to get responses takes too long.
Also businesses still use charge accounts with each other, backed by themselves. These low to mo interest temporary accounts allow money and products to flow quickly. Dnb helped to facilitate setting up those approvals.
i thought once I was found, but it was only a dream.
> > avoid storing all of this sort of data to begin with!
> Gawd what a stupid suggestion.
Based on my 20 years in information security, I'd say that's the very BEST suggestion to start with. Not only is it very effective, it's very COST EFFECTIVE. Twenty years ago, a great many companies used social security number as a handy identifier for people. Now we don't do that so much - there is no need to use SSN as a customer ID or employee ID, and there is great risk in doing that. So just don't store anybody's SSN, and you can never leak their SSN. The government agency I worked at before my current job was finishing up the process of removing SSNs from all databases when I left.
Companies who take payments by credit card only need the card number once, at the time of payment. Yet many of them kept the CC number laying around in a database for no good reason. Smart companies prevent big leaks of credit card numbers by simply not storing credit card numbers. Charge the card and be done with it - no need to store the number.
If the "tokenized forms of the CC number" can be used to charge the card, it probably shouldn't be made public.
If many customers will legitimately want to do further purchases, and for some reason entering the CC number is a major hurdle (both propositions that should be proved, not assumed) you can actually store it without storing it, in a way.
Certain customers can make purchases from us without re-entering their CC, but the CC number isn't stored on the web server, nor in the database that drives the web site, nor in any other system that stores data to be retrieved by these systems. None of our customer-facing systems, or systems that allow data retrieval of any kind, store credit card data. Instead, credit card information is stored on an isolated system which only accepts commands and returns "ok" or "failed". All other systems in the company can only send a command "please charge the card for customer #312" - there is no mechanism to retrieve data from that system. So our database and systems in general don't store CC data or other sensitive information, but we can still use customer CCs because it's stored only in, and can be accessed only by, the one hardened system. So that's an extension of "don't store sensitive data you don't need to store - and don't sensitive data in systems you don't need to store it in".