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.

Risk

6/19/2005
08:54 PM
Patricia Keefe
Patricia Keefe
Commentary
50%
50%

Data Security Requires A Group Effort

Forty ... million ... credit cards. MasterCard, Visa, Discover, and American Express. That's enough accounts to represent roughly one card each for 19% of the U.S. population that is 18 and over.

Forty ... million ... credit cards. MasterCard, Visa, Discover, and American Express. That's enough accounts to represent roughly one card each for 19% of the U.S. population that is 18 and over.In the last four months we have had at least 14 episodes of exposed data--be it by loss, theft, or hacking. Four of these incidents involved more than a million accounts, but the hacking of CardSystems Solutions last week is the hands-down winner, multiplying by a factor of 10 the number of affected accounts from the next biggest breach from two weeks ago--Citifinancial's 3.9 million accounts.

In this latest incident, roughly 13.9 million of the accessed accounts are MasterCards and about 20 million are Visa cards; Discover and American Express cards account for the remaining 6 million or so accounts.

In most of the 14 data breaches, common sense and or the application of basic security measures appeared to have been lacking. In many of these cases, the victimized companies moved to change their security procedures following the often belated revelations of the breaches.

And so it is with CardSystems. MasterCard's Data Protection policy requires most third-party processors to build and maintain a secure network and implement certain security processes, but whatever CardSystems had in place, it wasn't enough. Following a security audit, the credit processor apparently is changing its security procedures.

But there's no sense getting your knickers in a twist over this one, assures MasterCard. Social Security numbers and other identifying information are not stored on its credit cards, so our identities are safe. And the company claims that only about 68,000 of its affected card holders are at a high level of risk. The other three card issuers haven't had much to say publicly.

So I guess we're all supposed to relax now. Except that we won't. A recent survey by the Cyber Security Industry Alliance found that consumers want something done about the myriad of computer assaults peppering their systems--phishing, viruses and spam--but they don't trust the federal agencies most in a position to legislate protections--Congress and the Federal Trade Commission - to do the right thing. According to another recent survey by Javelin Strategy & Research, consumers think financial institutions focus too much on ID theft resolution, rather than prevention and detection.

Those survey respondents probably won't have to wait long to see some action. My guess is we will now see Congress rush to quell consumer outrage by hastily passing some laws. After all, there are at least four identity-theft-related bills floating around Congress right now, with more on the way.

The thing is, we need a lot more than a federal mandate ordering holders of our data to inform us when it is lost or stolen. That's closing the barn door after all the horses have left. We obviously need to mandate some level of security, and penalties for failing to provide it, since on their own, the data aggregators don't seem able to learn from, or react to, recent history. But thanks to this latest theft, we may have missed the window for some well-thought-out legislation. There is nothing like front-page headlines, angry voters, and the chance the legislators themselves may be victimized to fuel a rush to legislation.

You would think that after the first round of publicized breaches--if not the first round of blustering politicians--a light would have clicked on throughout the tiers of companies involved in collecting and aggregating sensitive consumer data. You would have thought they'd have scrambled to ensure the most basic level of security for this data: Firewalls. Antivirus measures. Encryption. Authentication. New protocols. Overnight shipping and notification for computer tapes. You can doubtless think of more. Some of this will take time to implement, some can be done quickly, and some steps are being taken now, notably at two victims, Bank of America and Visa.

This would be good, but it's not good enough. We don't need a piecemeal approach, every aggregator scrambling for themselves. It's clear the holders of our data are intertwined with one another. And if the industry is smart, they'll lay the groundwork themselves, instead of waiting for Congress to step in.

Last week, we saw the first rustlings of a collective consciousness on this issue. The Liberty Alliance, whose members include vendors, government agencies, and businesses, announced the Identity Theft Protection Group, which will try to provide a group effort toward fighting identity theft. The working group will be headed up by Michael Barrett, VP of security and architecture for American Express.

While it's early yet to divine any specifics, such as target areas or a timetable for something concrete, this is a good sign that someone is paying attention.

More immediately, industry-specific group efforts can pay off. We did it with EDI, we did it with ERP, and we're doing it with RFID right now. What am I talking about? Market-leading companies using their leadership positions like a club and insisting that anyone who wants to do business with them must install and use certain technologies and procedures. It's simple, it works, and it's an opportunity for IT to showcase its leadership, vision, and business acumen. In the case of EDI, vendors pushed by the largest customers speaking as one responded, first by meeting the standard insisted upon, and then by creating PC-based versions of their technology to ensure that companies further down the food chain of suppliers and manufacturers could afford to get on the train. That's what made EDI work. And it will be a big part of making RFID ubiquitous.

We need to do this with data aggregation. We need the credit-card issuers, processors, and reporting bureaus to put aside competitive issues and get together, figure out some security standards, procedures, and protocols, and then to lay down the law throughout the data chain.

We need the enormous political energy and attention that has gone into something silly, such as a small group of overpaid athletes doping themselves, instead diverted into the protection of sensitive personal and financial data.

Just imagine if the regulators and the government announced Monday that no more corporate mergers would be approved until this mess is cleaned up. You can bet the banks would have their acts together in no time. But still, it wouldn't be enough.

This is a cross-industry issue, and it can only be addressed with cross-industry cooperation. IT must help lead the way. We have the know-how. But if it takes legislation to make it so, let's get on with it, before every credit card out there becomes worthless and we start seeing ourselves coming and going.

Comment  | 
Print  | 
More Insights
Comments
Oldest First  |  Newest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/25/2020
Hacking Yourself: Marie Moe and Pacemaker Security
Gary McGraw Ph.D., Co-founder Berryville Institute of Machine Learning,  9/21/2020
Startup Aims to Map and Track All the IT and Security Things
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/22/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15208
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, when determining the common dimension size of two tensors, TFLite uses a `DCHECK` which is no-op outside of debug compilation modes. Since the function always returns the dimension of the first tensor, malicious attackers can ...
CVE-2020-15209
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, a crafted TFLite model can force a node to have as input a tensor backed by a `nullptr` buffer. This can be achieved by changing a buffer index in the flatbuffer serialization to convert a read-only tensor to a read-write one....
CVE-2020-15210
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, if a TFLite saved model uses the same tensor as both input and output of an operator, then, depending on the operator, we can observe a segmentation fault or just memory corruption. We have patched the issue in d58c96946b and ...
CVE-2020-15211
PUBLISHED: 2020-09-25
In TensorFlow Lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, saved models in the flatbuffer format use a double indexing scheme: a model has a set of subgraphs, each subgraph has a set of operators and each operator has a set of input/output tensors. The flatbuffer format uses indices f...
CVE-2020-15212
PUBLISHED: 2020-09-25
In TensorFlow Lite before versions 2.2.1 and 2.3.1, models using segment sum can trigger writes outside of bounds of heap allocated buffers by inserting negative elements in the segment ids tensor. Users having access to `segment_ids_data` can alter `output_index` and then write to outside of `outpu...