Popper is an excellent reporter on technical matters. His recent book “Digital Gold: Bitcoin and the Inside Story of the Misfits and Millionaires Trying to Reinvent Money” and related articles in The New York Times show a deep understanding of technological, economic and social issues relating to crypto-currencies. However, he appears to have become a victim of “voodoo statistics” when he tries to explain how the data indicate that the number of account hijackings is falling.

Popper uses various statistical sources to demonstrate that account hijackings, while rising in number of cases, incur less cost overall. Unfortunately, in a situation where perhaps 95 percent of account hijacks, according to the 2015 Verizon DBIR (Data Breach Investigations Report), which is available from http://www.verizonenterprise.com/DBIR/2015/, never make it to the survey companies and the media, it is poor statistical analysis to draw meaningful conclusions from less than 5 percent of the total number of incidents.

If you accept the 95 percent number (and you don’t have to), then, if losses from account hijacking go from $100 billion to $200 billion say, reported losses would increase from $5 billion to $10 billion. Yes, the number doubles in both situations, but now unreported losses have gone from $90 billion to $180 billion, suggesting an enormous increase in impact of $90 billion in unreported losses versus the $5 billion reported. Now, if we assume that, with the increased volume, the percentage reported drops to say 3 percent, we have $6 billion in reported losses—a mere $1 billion increase when the actual increase is $100 billion. This is very much a case of the tail wagging the dog. A small change in percentage reported versus unreported can have a huge impact on our estimates, easily switching analysts from one conclusion to another.

From the rapid-fire news reports of major data breaches, one might easily presume that data breaches are indeed way up in both number and size. Also, when ID theft occurs, the true anguish of re-establishing one’s credit credentials is barely seen in public, but it does exist and it is considerable. Popper’s claim that ID theft has been declining is in question with recent breaches, such as the one at the government’s Office of Personnel Management and the notorious Ashley Madison breach, making the headlines. Popper does state that the apparent downward trend of ID thefts will change and head upwards. However, it’s doubtful that the number of ID thefts actually went down in the first place.

I can understand Popper wanting to express some hope that we might be deflecting the avalanche of data breaches leading to account hijacking and ID theft. But the basis for such optimism is shaky. While such reporting may make individuals more optimistic about the directions of the consequences of data breaches, it serves to reduce the pressure on companies and government agencies to improve their data protection and incident response programs, which is not a good thing.

Allan raised may of the critical issues described in the WSJ article and added that medical identity theft is underreported. He was right, and still is. If it has taken all this time for the matter to appear on the front page of a major newspaper, then the subject has certainly not received the attention it warrants. Seven years of lost time is huge in the cybersecurity arena where events typically occur in milliseconds.

And the health industry appears to have done little to alleviate the problem. I recently advised someone to request that their health insurance company change the patient’s insurance coverage number following the Anthem breach and in response to clear evidence that stolen identities were being used for various nefarious purposes. The insurance-company employee responded that there wasn’t any way in which they could make the change … and, besides, no one else had requested such a change before. Of course, that is a ridiculous response. When you are aware that a payment card has been lost, stolen or otherwise compromised, financial institutions are quick to issue a new card and cancel the old card to limit their own losses. It would appear that, in the health-services industry, the burden is firmly on the insured. Perhaps the losses to the health industry itself are not particularly significant. And furthermore, some health-services providers may be actually benefitting from such fraud. After all, they do not appear to be liable if someone comes in for medical services using a valid health-insurance ID.

As Allan’s column and the WSJ article point out, the consequences of medical identity theft can be far greater in terms of physical safety than the losses incurred in financial fraud. The fact that HIPAA might actually work against resolving the issues and not protect valid insured individuals from the impact of medical identity theft is unconscionable. The WSJ article lists six consequences ranging from having all one’s benefits stolen and having valid claims denied through loss of insurance, unjustified out-of-pocket payments, cost of fixing credit reports and resulting lowering of credit scores, to being unable to access one’s own health records because HIPAA protects the health information of identity thieves that are co-mingled with victims’ records. It should be noted, however, that in an August 14, 2015 Letter to the Editor “Don’t Blame the Poor Victims of Medical Identity Thefts,” Jennifer Comerford claims that the article’s assertion that medical ID thieves are protected by medical-privacy laws is in fact not the case. Comerford states that “All individuals should be aware that they have the right to appeal refusal of access to their medical records.” If this is indeed true, we are being misled big time by those who claim otherwise.

I’m glad that Allan’s issues are at last making it to mainstream media. Perhaps legislators will recognize the failing in their laws and correct them, even if it means that a qualified third party (not insurance companies) is given the right to review the claims records and determine which of them are fraudulent. If a parallel law to the Fair Credit Reporting Act, which pertains to financial institutions were established, namely, that the victims have very limited liability (say $50) and that it is up to the vendor (bank or insurance company or health services provider) to either eat the losses or go after the thief, I’m sure that we would see a significant drop in this type of criminal activity.

We must not forget, however, that (differently from U.S. financial institutions) insurance companies are regulated by States rather than the Federal government. This makes the task more challenging but no less worthy. It’s time to eliminate this insidious crime that not only causes financial damage but can lead to physical harm or worse.

Finally some reporters came to the conclusion that the root cause of the outage was the Draconian firing practices by ICE (Intercontinental Exchange), on taking over NYSE Euronext, which eliminated of 40 percent of NYSE’s staff including those with decades of experience running the NYSE’s systems. Apparently this loss of expertise meant that those remaining, with relatively less experience, had much greater difficulty in attempting to bring the systems back.

I can relate to all of the above. In the 1970s I worked for SIAC (Securities Industry Automation Corporation) beginning soon after its inception. SIAC was formed from merging of the IT (then EDP) department of the NYSE with the IT department of its much smaller sibling, the Amex (American Stock Exchange). At that time, SIAC ran both exchange’s computer systems supporting the two trading floors and back-office clearance and settlement systems. The NYSE had higher-end expensive redundant trading-floor systems which were designed to fail over automatically to “hot” backup systems not once, but twice, with no loss of transactions. The Amex, in contrast, ran two independent simpler and cheaper systems. If one failed, Amex operators threw a physical switch from one system to the other and the couple of transactions not processed in the switchover were re-entered manually.

During the 1970s computers were orders of magnitude less reliable than they are today. Hardly a day went by that the huge (for that time) IBM computers had to be IPLed (or rebooted) following a component failure or a software abend (abnormal end). These procedures often meant that trading had to be halted until the systems could be brought back up. To overcome such outages, the NYSE installed what was called “large core storage” or LCS. LCS, as the name implies, was high-speed memory comprising tiny donut-shaped magnets with wires running through them. The idea was that LCS would be shared among all three active computers systems … the primary system, hot backup and warm backup. If the active system went down, the hot backup would pick up instantaneously without the loss of a single transaction using up-to-the-second data stored in the common LCS. If the backup system failed also, then the third system would be brought online and would also pick up the most recent transaction data from the LCS.

Much to everyone’s surprise, the NYSE experienced a whole series of outages over a given period of time compared to hardly any downtime at the Amex. How could this be? It turned out that, from time to time, the active NYSE system corrupted LCS data, which caused it to fail. The other two systems, in turn, picked up the corrupted data and also failed. The simple answer to the problem was to isolate the systems and simplify recovery as the Amex had done. Here simplicity trumped complexity.

My other experiences, which support the claim that ICE had iced experts who could have possibly handled the recent outage more expeditiously, were during my tenures as a senior IT executive at two financial services companies. It became very clear to me, in both cases, that the health and well-being of computer systems frequently depend on a handful of individuals, many of whom were involved in the development of the original systems and had experienced a host of problems, which they had learned to fix through bitter experience. Most of the knowledge was in their heads, even though documentation on the applications and operational procedures usually existed. I learned to value those individuals and depend on them to deal quickly, effectively and selflessly with issues as they arose. They were the real heroes of keeping the systems humming.

—-

There have been quite a number of previous vehicle software malfunctions (call them “bugs,” “glitches,” or what have you) in the past, such as the Toyota Prius recall in 2010 affecting the anti-lock braking system … see http://www.bloomberg.com/slideshow/2012-08-03/the-big-cost-of-software-bugs.html#slide9 and the more recent (July 2015) Prius recall for software that might shut down the hybrid system while the car is being driven … see http://www.reuters.com/article/2015/07/15/us-toyota-recall-idUSKCN0PP0EF20150715

But, up until now, affected systems have been vehicle-control systems which are clearly under the auspices of the automobile manufacturers and the latter have assumed liability.

However, the most recent such matter, in which Fiat Chrysler agreed to recall 1.4 million vehicles to fix a security bug that allows the infotainment system to be hacked remotely and the attacker to jump over to the control systems, is the first of its kind, as far as I know. But it is unlikely to be the last. The event is described in Andy Greenberg’s article in his July 24, 2015 article “After Jeep Hack, Chrysler Recalls 1.4M Vehicles for Bug Fix” available at http://www.wired.com/2015/07/jeep-hack-chrysler-recalls-1-4m-vehicles-bug-fix/

This emergence of software-related recalls reminded me of my letter to the editor, which was printed in The New York Times on June 18, 1999, with the title “Are ‘Viruses’ Naughty by Nature?” available at http://www.nytimes.com/1999/06/18/opinion/l-are-viruses-naughty-by-nature-222801.html

In the letter, which was in response to a June 14, 1999 news article, “Illness as a Metaphor for Computer Bugs,” I compared the expectation of recalls on vehicles for safety defects to the lack of liability on the part of software developers, as follows:

“When we buy a car, we expect certain safety features to be built in, and if they don’t work, then the vehicle is recalled and fixed at no charge. We should expect the same guarantee from software developers.”

It is interesting to note that this is now actually beginning to happen, albeit by a circuitous route. Granted it is because of a vulnerability in software running on a motor vehicle that is not directly in control of safety-related features, but could this be a precedent for software resident on all devices (the Internet of Things), vehicles, etc.? If it becomes so, then we are at the start of a sea change in how software is viewed, especially IT software that can be bridged across to control systems … which eventually may be ALL software.

I had called for more rigorous design, development and testing of security-critical and safety-critical software in my book “Engineering Safe and Secure Software Systems,” (Artech House, 2012) especially when such systems are connected and interoperate, but had never expected that the issue would rear its ugly head so soon … shades of the movie “The Day After Tomorrow,” or perhaps William R. Forstchen’s book “One Second After.”

We have certainly arrived at a new era of software dependency and are beginning to experience the hazards of interfacing Web-facing software with safety-critical systems. If it were up to me, I would call a halt to all these systems until a reliable set of standards and certifications have been fully established but, of course, that’s not going to happen. The pressure to innovate, particularly in the area of automating road vehicles, is too great. The juggernaut cannot be held back. Instead we will be subjected to repeated software malfunctions and failures, vehicle takeovers, and all that they imply and, as with hacks affecting commercial and governmental information systems, there will be a lot of “tut-tuts” by politicians, followed by ineffective attempts to regulate minimally. And then life will go on … until the “big one.” But, by then it will be too late to do anything.

As Forstchen describes in his novel, the only vehicles running may be from decades earlier, when there were no electronics in them. But how many of these antiques are still operating? And what about getting gasoline? The delivery trucks wouldn’t be drivable either and the pumps wouldn’t work at the gas stations, as we in the North-East (USA) discovered in the aftermath of Hurricane Sandy. Sandy was an act of Nature that we couldn’t prevent, although we might have been better prepared to deal with the consequences. The catastrophic failure or mass takeover of vehicles can still be avoided, if we have the mind to do it.

As an aside, the remote control of vehicles is by no means new. It has been available for well over a decade with such systems as GM’s OnStar. Not only do these systems open the doors when you are locked out of your vehicle, automatically call for help if they detect that you’ve been in a serious accident, and know your exact location as they provide driving directions, but they also have the capability to disable your vehicle if you report that it has been stolen and they are able to listen into conversations, although GM apparently turned down requests by law enforcement to allow their monitoring of in-vehicle conversations. There is a real and present danger that OnStar and similar systems could be hacked, giving hackers all the OnStar capabilities or that a malicious insider could cause havoc. Newer capabilities, such as steer-by-wire, only give hackers more opportunities to play with.

I first reported on the work by researchers Charlie Miller and Chris Valasek in a presentation “Securing Cyber-Physical Software,” at the OWASP AppSec USA Conference, in New York City, in November 2013, following the publication of my book Engineering Safe and Secure Software Systems (Artech House, December 2012). I showed the video of Andy Greenberg at the wheel of a Toyota Prius at the presentation and remarked that researchers Miller and Valasek were sitting in the back seat of the Prius laughing out loud as they caused all sorts of dangerous vehicle activities. Greenberg’s article appeared in the August 13, 2013 issue of Forbes magazine and is available online at http://www.forbes.com/sites/andygreenberg/2013/07/24/hackers-reveal-nasty-new-car-attacks-with-me-behind-the-wheel-video/ Miller and Valasek had ripped apart the dashboard of the Prius and connected their laptops. They showed how they could take over many of the operational functions of the vehicle. The industry essentially pooh-poohed the research, saying that it was not practical to perform this experiment in the real world. Much as the airline industry has done the same when responding to researchers’ aircraft systems hacks.

Two years later, Greenberg is reporting on the latest research by Miller and Valasek, referenced above. Here the access is remote over the Internet and the Jeep SUV itself has not been tampered with in any way. The results are especially hair-raising as you can see in the video contained in Andy Greenberg’s July 21, 2015 article “Hackers Remotely Kill a Jeep on the Highway—With Me in It” at http://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/ As before, the industry has downplayed the research, stating (in Perlroth’s article) that “anyone with physical access to the car could just as easily cut the brakes.” It seems they missed the point. Fiat Chrysler says “they have issued a patch” and that it was irresponsible of the researchers “to disclose the vulnerability to the public.” The manufacturer’s spokesperson said that the company “monitors and tests its systems to identify and remove security vulnerabilities.” Well, they clearly didn’t do a great job here. Did they perform the exhaustive “functional security testing” that I have been advocating for years? … Apparently not.

It is really wearying to warn of obvious dangers as we rapidly expand our information and control systems and increasingly tie them together. This is the case with cybersecurity, where today’s data breaches were anticipated more than a decade ago (per my 2001 Congressional testimony and statements by many others far more prestigious than I at that time). The risks are increasing rapidly with control systems as they begin to interoperate with information systems. As I have written many times, there is a major gap in expertise between infosec professionals and safety engineers as systems are brought together and this gap needs to be addressed, as do certification standards. Such certification requirements are spelled out for aircraft and land vehicles, but they are obsolete. Granted that a malfunction or failure of an entertainment system is not nearly as hazardous as a malfunction or failure of a flight-control or vehicle-control system, but when a bridge between these systems is created, then a hack on the former can lead to compromise of the latter. Yet we continue to build systems that are vulnerable with equanimity and blame the deliverers of the message for inappropriately publicizing the dangers. The aircraft and automobile (and train and ship) industries have had fair warning and clearly have not done enough to correct the situation … in fact they are making it worse by allowing the introduction of inadequately-tested new technologies. What will it take for manufacturers to recognize that they are endangering the populace in their pursuit of cool new features in order to give themselves a marketing edge? And how much greater will the risk be when cars get automatic pilots?

Much of the blame for the data exfiltration has been assigned to OPM’s using an older version of Einstein, a government built intrusion detection system (IDS). Einstein’s the upgrade to an intrusion prevention system (IPS) has been hampered by delayed funding and approvals, according to the article “Breached Network’s Security is Criticized” by Damian Paletta on the front page of The Wall Street Journal of June 24, 2015. From my experience, the move from IDS to IPS is not a trivial exercise, since one needs to be careful not to block important messages. It takes time and expertise to fine-tune IPSs. However, the problems at OPM appear from reports to be much more extensive.

However, more importantly, no organization depends solely on IDS/IPS to manage its security. There is a whole range of measures, including strong, preferably two-factor, authentication, role-based authentication, and data masking. With data masking sensitive data fields are only made available (for read, write, and/or modify) to those with a need-to-know. The WSJ article also mentions separating data so that getting access to a single database does not reveal the whole picture of someone’s identity. This method has been discussed for some time, but is not trivial to implement. It first depends on precise data classification. Then the computer applications have to be designed to perform the complex operation of merging data and then breaking them apart. It is important to recognize that this method, along with encryption, is only effective for protecting raw data. If the attacker goes through an application with privileged access rights, then the system will bring together (and decrypt) the data and make the data available in aggregated (and cleartext) form. Believing that data aggregation and encryption are the answer is a myth of data protection held by many, including lawmakers.

The only approach that has a chance of working is a combination of effective IAM (Identity and Access Management) system, importantly including stringent registration procedures, and instrumenting applications so that you can actually know who is accessing and leaking what data in real time. The other stuff is nice to have, but doesn’t do much if the attacker steals legitimate credentials through spear-phishing or social-engineering means.

So … data masking is an important tool for ensuring that only those with a need-to-know see certain very sensitive information, but implementing data masking requires a strong understanding of what data are needed by whom and it can take a lot of programming work, especially with today’s integrated systems of systems.

The second issue is masking (or not disclosing) information so that the true extent of a breach is not made known to those affected and to the public at large. This could be a case of not actually knowing what was taken, although this does not appear to be the major issue in the OPM case as described in the article “Officials Masked Severity of Hack” by Devlin Barrett and Damian Paletta in the June 25, 2015 issue of The Wall Street Journal, where obfuscation appears to have been deliberate.

In many cases, an organization does not know what data were taken, when, and by whom. This is due to weak monitoring of networks and a lack of instrumentation within the applications. The former is relatively easy to fix—you just buy some products—but the latter takes a lot of work, especially if a software rewrite is needed. Of course, it is much better to include the need for instrumentation in requirements phase in the system development lifecycle, and carry those requirements through the design, development and testing phases. I wrote about this in an article “Creating Data from Applications for Detecting Stealth Attacks,” in the September/October 2011 issue of CrossTalk Journal, see http://static1.1.sqspcdn.com/static/f/702523/14121186/1315886331850/201109-Axelrod.pdf?token=0%2FFV5vW3t5qnshouG5UH3mKmNzE%3D

When you look at all the things that need to be done, their cost, resources needed and time to implement, one might despair of any ability to close the flood gates or, unfortunately in many cases, the “barn door.” So, what is there left to do? If protection does not solve the short-term problem, then one is left with deterrence and avoidance. Deterrence in the cyber world is highly questionable, especially as attribution is fraught with errors … sources can be spoofed. Sanctions are not as effective for cyber warfare as they may be for kinetic wars.

I ploughed through the article and found it quite informative. As someone whose first language was FORTRAN and who enjoyed programming in APL, I found it interesting to read Ford’s views and experiences. However, as an InfoSec professional, I was hugely disappointed at the lost opportunity to inform his presumably-large audience of the importance of secure coding and of the many vulnerabilities that are typically embedded in computer programs. In fact, there are only a couple of references to information security in the entire piece. One is about passwords, where he writes:

“We didn’t talk about password length, the number of letters and symbols necessary for passwords to be secure, or whether our password strategy on this site will fit in with the overall security profile of the company, which is the responsibility of a different division.”

Not my problem. Sounds like a cop-out to me.

The other mention of security is in regard to delays that a software project might experience:

“First, I needed to pass everything through the security team, which was five months of review …”

Right. Security is always the fall-guy when developers are looking for excuses as to why they are late with their projects. If they had built security in from the start there would have been minimal impact on the project’s timeline. Bolting security on once the programs are completed is always more expensive, less effective, and can cause inordinate delays.

Ford also waxes poetic about open-source software, but never mentions the Heartbleed and Shellshock fiascos … see my November 3, 2014 BlogInfoSec column “Heartbled and Shellshocked … What Can We Do?”

While the coding issue of Bloomberg Businessweek makes a heroic effort to bring knowledge of programming to the populace, it does everyone a disservice by not addressing information security and misses a wonderful opportunity for teaching the public of the importance of secure coding and security testing. As long as programmers’ prevalent view is that information security is someone else’s problem and that security reviews hamper project progress, we are not going to see very many applications that are secure, and cyber attacks will continue to be successful at an ever-increasing rate.

Oh, by the way, there is no need to spend $5.99 on a newsstand copy of the magazine, as I did. The complete issue is available free at http://www.bloomberg.com/graphics/2015-paul-ford-what-is-code/ in a more entertaining interactive version.

The GAO (US Government Accountability Office) released an April 2015 report, GAO-15-370, on the cybersecurity of air traffic control and avionics systems, with the title “Air Traffic Control: FAA Needs a More Comprehensive Approach to Address Cybersecurity as Agency Transitions to NextGen,” which is available at http://www.gao.gov/assets/670/669627.pdf

The issue about malevolent individuals or terrorists hacking into air traffic and aircraft control systems has been discussed at length. The usual response is denial from the oversight agencies and contractors. Well, yes, researchers demonstrated that they could hack into avionics systems using a smart phone, but that, according to the FAA, EASA, Honeywell and Rockwell Collins, would not be feasible in “the real world” … see my April 21, 2014 BlogInfoSec column “It’s About Time … Tamper-Proofing Aircraft Systems” and also my prior April 10, 2013 BlogInfoSec column “Hacking Avionics Systems.”

So now that we have an authoritative view of the situation from the GAO, what should we do about it? In their report, the GAO first enumerates the following three cybersecurity challenge areas faced by the FAA:

1. protecting its air traffic control (ATC) information systems,
2. securing aircraft avionics used to operate and guide aircraft, and
3. clarifying cybersecurity roles and responsibilities among multiple FAA offices.

The GAO then suggests that the Secretary of Transportation instruct the FAA to do the following:

• As a first step to developing an agency-wide threat model, assess the potential cost and timetable for developing such a threat model and the resources required to maintain it.
•  Incorporate the Office of Safety into FAA’s agency-wide approach by including it on the Cybersecurity Steering Committee.
• Given the challenges FAA faces in meeting OMB’s guidance to implement the latest security controls in NIST’s revised guidelines within one year of issuance, develop a plan to fund and implement the NIST revisions within OMB’s time frames.

These are all worthwhile demands, but they are neither sufficiently comprehensive nor do they suggest the required level of urgency. The threats to and vulnerabilities of these systems are growing daily. Security guidelines need to be implemented today, if not sooner. Over the past several years, we have seen pilots replacing piles of paper for navigation information with tablets, with apparent fuel savings in the millions of dollars just from the reduced weight. At some point, these off-the-shelf systems will likely be connected to airplanes’ control systems. Sophisticated passengers, well versed in hacking methods, can supposedly gain access to aircraft flight management systems from ports under their seats. And who knows what well-funded nation states might be able to do?

In my book, “Engineering Safe and Secure Software Systems,” (Artech House, 2012), I specifically address issues that arise from combining security-critical information systems and safety-critical control systems. I describe in detail the development lifecycles of both security-critical and safety-critical cyber-physical systems and how both lifecycle processes must be brought together with expertise in both cybersecurity and system safety brought into the picture. It is now more than two years since my book was published and I wasn’t the first to raise these issues by any means.

What will it take to make all this a top priority and accelerate and expand these government efforts? Perhaps it has already happened. There was an accident on May 9, 2015 in which an Airbus A400M military cargo and troop transport plane crashed on a test flight resulting in the deaths of four persons. Several weeks later it was revealed that the crash was caused by faulty software installation, as described in Mike Wheatley’s article “Faulty Software Install Led to Airbus A400M Plane Crash,” in SiliconAngle, June 1, 2015 … see http://siliconangle.com/blog/2015/06/01/faulty-software-install-led-to-airbus-a400m-plane-crash/

There have been other software failures in modern aircraft that fortunately didn’t lead to loss of life. Do we have to witness a major disaster before the authorities take this matter more seriously and place tighter deadlines on putting stringent security-safety measures in place? Implementing security controls “within one year of issuance” of NIST’s revised guidance isn’t good enough, by far. We need them now.

There have also been concerns voiced over the accuracy of such data and whether we might be inappropriately categorized to our detriment. In fact, this was a question that was asked during my lecture on “The Fall of Privacy … and the Rise of Anonymity” on May 8, 2015, which I presented as one of the Technology and Policy Speakers Series talks at Stony Brook University.

My response to the question was that the high proportion of inaccurate personal data is indeed a major issue and that many of us suffer at some level or other as a consequence. The problem is not resolvable unless we are aware of the misrepresentations, and we are unlikely to become aware until either something bad happens or unless we are given legally-mandated access to our own personal data and with the ability to correct them, which has been a requirement in the European Union for 20 years under their 1995 Data Protection Directive.

Because of the vastness of big personal data banks, it is highly unlikely that false and inaccurate data will be corrected unless there are mechanisms that provide the ability to detect questionable data and fix them. On that score, there was a thought-provoking article, with the title “How Not to Drown in Numbers,” in the May 2, 2015 Sunday Review section of The New York Times by Alex Peysakhovich, who is a behavioral economist and data scientist at Facebook, and Seth Stevens-Davidowitz, who is an economist,.

Peysakhovich and Stevens-Davidowitz’s article points out that, while the use of big data is “amazing” for (say) detecting “whether a picture has a cat in it,” it is “not enough” for “important decisions about your health, wealth or happiness.” To counter this deficiency, the authors recommend supplementing big data with small data in order to “contextualize” the data. That is to say, through the use of surveys, analysts can begin to understand the true meaning of the data.

I recall a situation early in my career where we were analyzing the likelihood that aging credit card accounts would eventually be paid. The sophisticated statistical tools provided minimal help. I requested more information as to why cardholders were not paying, such as delinquency, criminal behavior, questions about the validity of some charges, or the demise of the cardholder. Unfortunately, this information was not to be had, so the statistical analysis remained relatively ineffective.

This brings us back to personal data in general. As with so much in data and metrics, the easy-to-collect stuff (i.e., big data) provides the basis for most decisions. The relatively more difficult-to-collect and costlier stuff (i.e., small data) is frequently ignored because of the relatively high data collection cost of surveys and the need for higher-paid specialists to analyze and understand the small data. When it comes to personal data, not only is the collection of big data fraught with accuracy problems but also the use of resulting analysis in making momentous life-affecting decisions, such as granting insurance or a mortgage, might be based on false information.

Unfortunately we seem to be going down the path of bigger and bigger data and less and less understanding of those data. That does not bode well for our society which is increasingly dependent on data regardless of their accuracy or completeness.

By the way, Ross posted an earlier piece on August 20, 2014 on IEEE Spectrum with the title “Why Can’t Government Run Vehicle-to-Vehicle Communications?” at http://spectrum.ieee.org/cars-that-think/transportation/infrastructure/why-cant-the-government-run-vehicletovehicle-communications citing the same lack of funds as the reason.

I have felt for some time that safe and secure vehicle control systems and vehicle-to-vehicle communications will need a carefully constructed infrastructure that informs vehicles of road conditions, temporary disruptions (road works, accidents, dangerous weather), and communications between the infrastructure and vehicles. Yet most of the conversations about self-driving vehicles in the U.S. tend to center around on-board systems and communications with the Web.

For the first time I noticed an article about self-driving cars in which it was actually admitted that there have indeed been a number of accidents and crashes of these vehicles which try to replace the human senses but which only perceive the environment and other vehicles via video cameras, radar and other sensors. That is to say, there is no two-way communication.  In his May 16, 2015 Scientific American article “Google’s Self-Driving Cars to Hit Roads, with Steering Wheels,” which can be found at http://www.scientificamerican.com/article/google-s-self-driving-cars-to-hit-roads-with-steering-wheels/, Paul Lienert writes that “… Google disclosed that its self-driving … vehicles had been involved in 11 accidents on public roads … Not once was the self-driving car the cause of the accident [said project director Chris Urmson] … the cars had been hit from behind seven times, mainly at traffic lights, with a majority of the accidents being on city streets rather than on freeways.”

I must say that it is somewhat disingenuous to say that the self-driving cars didn’t cause any of the accidents. Granted it is not seen to be your fault if you are hit from behind, but, as many of us have experienced, if the car in front of you slams on its brakes unexpectedly, you, as the following vehicle, may not have much opportunity to stop in time. Be that as it may, it is apparent that it is not sufficient for self-driving cars to follow the rules of the road by themselves, they need to be more aware of what impact their actions may have on others. This supports the need for intelligent infrastructure and for ALL cars to be able to communicate with ALL the others and for a comprehensive, intelligent infrastructure.

In a column, “Car Talk: Vehicle-to vehicle communication is coming, Are we ready for it?” in the March 2015 issue of Communications of the ACM, Tom Geller differentiates among on-board sensors, such as rear-view cameras, V2I (vehicle-to-infrastructure), and V2V (vehicle-to-vehicle) technologies, with the latter two referred to generically as V2X technologies. The article is an excellent overview of the various technologies needed for autonomous vehicles to operate safely, although it doesn’t point out the greatly expanded cyber attack surface that these systems open up. There is clearly a need for threat modeling for these systems both independently and when connected to one another.

Aaron M. Kessler’s article “Hands-Free Cars Take Wheel, And Law Isn’t Stopping Them,” on the front page of The New York Times of May 3, 2015, describes how lawmakers and regulators are trying to catch up with the technology with minimal success.

Again we see the rush to bring these autonomous vehicle technologies to market without much-needed laws and regulations. Nor is attention being paid to securing these systems against cyber attacks. This is yet another example of looking to bolt on security and safety, after systems have already been deployed, at much greater expense and with much greater risk of successful cyber attacks, malfunctions and failures in the interim.