Support for this approach to risk recently came from an unlikely source, in the form of a DealBook article by Jesse Eisinger with the title “Uncovering the Human Factor in Risk Management Models,” which was published on page B7 of the April 4, 2013 New York Times. The author provides a history and expresses the thoughts of Dr. John Breit, who was the former “top” risk manager at Merrill Lynch.

In Eisinger’s article, we discover that Dr. Breit believes that “[i]nstead of fixating on [risk] models, risk managers need to develop humint … [namely] human intelligence from flesh and blood sources.” To gather such humint, Dr. Breit would socialize with junior accountants and others on the basis that: “They see things first. Almost every trading debacle was sitting on some accountant’s desk.”

If we apply the same thinking to information security, it makes good sense for infosec professionals to gather information from users and operators of systems, networks and devices in order to understand how they view security risks of their systems and operations. You will often find out that they know much more than you had realized about where the threats and vulnerabilities lie and what should be done about them.

Perhaps the following paragraph from Eisinger’s article is the most revealing:

“Take VaR [value at risk]. In Mr. [sic] Breit’s view, Wall Street firms, encouraged by regulators, are on a fool’s mission to enhance their models to more reliably detect risky trades. Mr. Breit finds VaR, a commonly used measure, useful only as a contrary indicator. If VaR isn’t flashing a warning signal for a profitable trade, that may well mean that there is a hidden bomb.”

Such a view can be extended from trading models to information security. We see what our intrusion detection and network monitoring systems tell us. The common threats and exploits are monitored, mitigated and deflected. For the most part, it is common that exploits, which we don’t detect, can lead to major data breaches. This presumption is based on the number of publicized occasions where victims appear to be unaware of attacks and only recognize them once another party, such as law enforcement or payment card processors (such as VISA), has detected them and pointed them out to the victim organization.

This takes us back to the personalization of risk. Risk models attempt to remove subjectivity and personal views, and to some extent they may do that. However, the highly subjective manner in which such models are developed and used often leads to their failure to represent reality. It would be far better if one were to recognize that humans still have major contributions to make in recognizing risks and assessing their impact, and use humint to supplement, and in some cases replace, ineffective risk models. Placing unwarranted faith in deficient risk models only exacerbates an already dangerous situation. On the other hand, if one accepts that personal bias is injected into the development and use of risk models, the resulting models depend very much on whom you ask for input as does the interpretation of the results.

It is important to include human factors when creating and running risk models. But it is also important to recognize the limitations resulting from “human frailty” and personal bias.

Whether or not the hacks effected in the lab environment are currently feasible, they are probably technically possible under the right set of conditions and become increasingly likely as systems are linked together forming systems of systems and cyber-physical systems, where the latter term is used to mean systems that result from combining Web-facing applications and embedded control systems.

In my book “Engineering Safe and Secure Software Systems” (Artech House, 2012), I describe how security and safety software engineers usually have different perspectives and tend to communicate within their groups rather than with other groups. This lack of communication across the safety and security disciplines means that safety-critical systems, such as avionics systems and autonomous (driverless) vehicle systems, may well not be secure enough when they are connected to Web applications, as is increasingly happening. This is because these two categories of system engineers have very different approaches to how they design, develop and test their software systems. With security-critical systems, the main focus is on protecting information assets, particularly intellectual property and nonpublic personal information, whereas for safety-critical systems, the goal is to prevent their malfunctioning or failure from harming humans and/or the environment.

It is just such hopping to one system from another system that creates the possibility that major damage might be incurred or inflicted. It is perhaps somewhat analogous to the recent appearance of the newest strain of bird flu where the virus is transmitted from chickens, which are asymptomatic, to humans, for whom the disease is often fatal. Thus, a hacker may access a control system, such as a flight management system, via a front-end Web-facing application. The Web application may not be damaged in any way, but the repercussions for the safety-critical system could be horrendous.

So what is the answer here? In the best case scenario, security-critical and safety-critical systems are not connected or connectable. However, even if they do not appear to be interconnected, a hacker might be able to bridge across from one to the other as Teso demonstrated.

It is also interesting to note that Teso claims that legacy systems are much more vulnerable to such attacks than are newer systems. He explains that newer systems receive more patches than do older ones. This is in contrast to the likelihood that legacy safety-critical systems are prone to be safer than newer systems because they were developed using programming languages, such as Ada, which intrinsically have higher integrity and resiliency than systems developed in currently-used programming languages. However, such legacy systems are unlikely to have much, if any, security built-in, since their designers and developer probably do not think that they needed to consider the possibility of external parties gaining access, much as in the 1960s, 1970s and 1980s, developers did not anticipate the need to use larger date fields … which resulted in the Y2K problem.

So now we have major security issues relating to safety-critical systems because their creators did not anticipate universal access as is provided by the Internet. The risk-mitigation effort for building security into safety-critical systems is potentially huge … orders of magnitude greater than Y2K remediation was, since the latter did not require that programmers, who were making the corrections, know much about the applications themselves. However, for the securing of systems that control aircraft, oil refineries, nuclear power plants, and the like, systems engineers must understand what the control systems do and where the vulnerabilities might lie. Thus we can expect a huge effort and enormous costs to be incurred to secure these systems properly. However, it is another case of pay now or pay later … and the tab down the road will be that much greater.

Nevertheless, decisions regarding confidentiality, integrity and availability are frequently made based on perception rather than reality. Consequently, infosec professionals must respond to the perceptions. This means that security and resiliency, together with dependability, need to be held to a higher standard for cloud services as compared to other means of delivering IT services, like it or not.

As I wrote in my book, Outsourcing Information Security (Artech House, 2004), a major benefit of having third parties perform a company’s IT and infosec functions is in the form of the service providers’ greater experience as a result of being able to hire and retain accomplished subject-matter experts covering a broader scope across clients. However, it is important to keep some level of expertise in-house to oversee these third parties and to be available in the event that it is decided to insource the services or transfer them to another provider.

What about security and privacy? Here, it is important for customer organizations to take control whether directly through internal staff or indirectly via trusted third-party managed security services providers (MSSPs). And it is also necessary to develop tools and approaches that will enable organizations to jump the many hurdles of cloud services security that are being presented to them.

An article, in the February 2013 issue of Communications of the ACM, by Ari Juels and Alina Oprea of the RSA Labs in Cambridge, Massachusetts, with the title “New Approaches to Security and Availability for Cloud Data,” (pages 64- 73), describes the problem well and suggests a solution. A key insight or the article is as follows:

“Creating incentives for [public] cloud adoption requires thinking beyond data encryption, which alone rarely provides confidentiality on [sic] data processed in the cloud or protects against tampering, corruption or loss of availability.”

The authors suggest real-time auditing by tenants or third parties to provide “security visibility” and “strong assurance of correct … operation.” The solution, which they advocate, involves a “small trusted gateway within the enterprise.” Two important factors, which they emphasize, are “data freshness”, along with “date integrity” (i.e., assurance against data tampering).

The mechanisms suggested by Juels and Oprea are well worth considering. They can really apply to both internal and external facilities and should be considered for both. However, I did not see much attention paid in the article to actual tamper-proofing. This is an area that also has great potential in resolving issues relating to the perception of security in the cloud as well as for internal systems.

I was also struck by the similarity of the Executive Order to Presidential Decision Directive (PDD) 63 issued in May 1998. This PDD called for the United States having “the ability to protect the nation’s critical infrastructure from intentional acts that would significantly diminish the abilities of the Federal Government to perform essential national security missions …” There was an immediate response to the PDD and I was involved in the one by the Banking and Financial Sector. While the PDD required action in four areas, namely: information sharing, outreach, research and vulnerability analysis, the only area that really showed results was the information sharing area. This latter effort resulted in the formation of the FS-ISAC (Financial Services Information Sharing and Analysis Center), which was launched in October 1999 by then Treasury Secretary Larry Summers. I was on the team, led by Stash Jarocki, which made the FS-ISAC happen and become the model for other ISACs. The FS-ISAC has grown in strength and membership and remains the primary example of information sharing between government and the private sector.

The technology behind the FS-ISAC allows for authenticated sharing of anonymous private sector cybersecurity related information, as well as the distribution of information provided by the government to members of the financial services industry. The two-way sharing of information without compromising the sources has been proven to be feasible. Therefore it is disappointing that the latest Executive Order does not encourage such two-way sharing but only requires the government to come up with ways to distribute information to which they have access.

Since supposedly an estimated 80 percent or so of the national critical infrastructure is in private hands, it follows that private-sector organizations are likely to see the majority of threats, exploits, vulnerabilities and incidents related to cybersecurity in general. It makes no sense that this information not be shared among companies and with the government as long as the sources of that information are protected by anonymity if necessary. As mentioned above, the technology to achieve this was developed some 15 years ago. Until and unless we can overcome the resistance to, and concerns about, such collaboration, limited proposals to share information that will help defend the nation’s critical infrastructure from intentional or accidental acts of cyber compromise will not be sufficient. Cybersecurity is different from many other types of threat to the national wellbeing in that there are ways of sharing information and collaborating on responses to threats and exploits that threaten neither individual privacy nor corporate intellectual property and reputation.

This is a call for action to establish meaningful information sharing across the board so that we might address the problem. In a much more meaningful way.

The article goes on to discuss issues relating to the fact that the data on the stolen laptop containing the data was not encrypted and also the various personnel and legal activates that resulted. But to my mind, the most important statement in the piece was by Dr. Robert M. Nelson of the Jet Propulsion Laboratory, which is part of NASA. He asked the question: “Why does NASA need personal data unrelated to our work …?” He also questions why they treated the data in “such a cavalier way” that resulted in the data residing unencrypted on a laptop, which had been left in a car, being stolen.

In my opinion, that question of the need to collect the data is the crux of the matter. The encryption is secondary. Why is so little thought being put into the potential consequences of collecting and distributing highly sensitive data?  I have long argued that convenience is no excuse. Rather that it was inconvenient for even authorized individuals to get at and replicate such data. We seem to be governed by the need to give quick and ready access to all manner of data and not upset the “users” by putting hurdles in their path.

Well, guess what … a little forethought and inconvenience is a small price to pay for the comfort of knowing that the data are protected and only released when absolutely needed and only then under strict monitoring and control. The multiple billions of dollars of intellectual property that is blatantly stolen every year could be easily reduced if it were strictly limited in access and distribution.

Yet even such an approach has its own limitations. Over time, controls over data become hazier and less stringent as those who understand the need to restrict access and distribution of particular information are bypassed or ignored as new requirements come into play. The dynamics of data creation, use and protection are constantly working against us. Perhaps one specific application required Social Security numbers, but nobody thought to block or mask SSNs for subsequent applications that didn’t require them. I wrote about this in January 2007 in an article “The Dynamics of Privacy Risk,” ISACA Information Systems Control Journal available at http://www.isaca.org/Journal/Past-Issues/2007/Volume-1/Documents/jpdf0701-the-dynamics-of-privacy.pdf

These ideas are clearly not new but, to be effective they need to receive adequate attention and the assignment of resources of suitable level and capability. I like to use the analogy of damming a river. The closer to the source, the easier and cheaper it is to construct a dam. If you try to dam a river estuary, the cost is many orders of magnitude greater. So it is with data. Restrictions close to the origin of the data are less costly and easier to implement than are attempts to corral the data once they are released to larger populations of users. Combine this with the difficulty in implementing effective identity and access management systems, and you have a situation that naturally leads to the kinds of data breaches and compromises that we see publicized every day.

Commercial software companies have long gotten away with taking no responsibility for the functionality of their software. As long ago as June 18, 1999, my letter to the Editor of The New York Times, with the title, “Are ‘Viruses’ Naughty by Nature?” was published. The letter was as follows:

“Re ‘Illness as a Metaphor for Computer Bugs’ (news article, June 14): In fact it is the biological analogy itself that most hampers attempts to eradicate the viruses and bugs that cost us hundreds of millions of dollars a year in the purchase of antivirus software, destroyed information and lost productivity.

The common impression that it all comes down to a battle between the virus creators and virus destroyers prevents us from recognizing the real culprits: the software manufacturers who are getting away with and even profiting from their own products’ deficiencies.

The push to bring new and improved products to market at the lowest cost results in program developers’ cutting corners. If we were to insist on having defenses built into the products we buy, there would be no need to suffer the consequences of virus attacks or to spend so much trying to defend ourselves against them.

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.”

What goes around comes around. Suddenly the two separate worlds of commercial software development and the safety of vehicles are converging. As I point out in my book “Engineering Safe and Secure Software Systems” (Artech  House, 2012), the cultures of information system software developers and of software safety engineers are very different and there is a question as to whether they can be brought together as is needed for driverless vehicles. Information system creators and operators, such as Microsoft, IBM, Google and the like, make no assertions with respect to the operability and fitness for purpose of what they write and sell. Common software contracts basically say that there are no guarantees … let the buyer beware! However, the automotive industry, as well as other industries, such as aviation, have to meet very specific standards for the software that they develop and insert into vehicles. Not so for commercial software. Therefore we have a disconnect, as can be seen in the Strumpf article.

The liability issues relating to driverless vehicles are but the start of a long and tortuous discussion about how we account for security and safety in cyber-physical systems. Commercial software companies will have to understand that the free ride that they have been able to maintain all these decades no longer applies when software is used to power life-threatening and harm-threatening systems. This will be a rude awakening for many, but is something that they are going to have to get used to if they hope to operate in the world of hazards.

“While it is commendable that GE is repatriating some of its appliance manufacturing to the U.S., it is unconscionable that they offshored such manufacturing in the first place. Businesses jumped on the offshoring bandwagon since there was a general, though misplaced, conviction that costs would be reduced overall. It is true that many corporations and consumers did reap benefits from lower direct costs, as well as savings from misguided tax laws that favored moving production abroad. It is now “politically correct” to announce when products are going to be manufactured stateside, as in the recent case of Apple Inc.’s recent decision to manufacture a line of computers in the U.S., as documented in the article, “A Mac That’s ‘Made in U.S.A.,” by Jessica E. Lessin and James R. Hagerty in The Wall Street Journal of December 7, 2012. The economics of the decision have changed in such a way, with lower relative employee and energy costs, so as to facilitate justification of the return of manufacturing to the U.S. However, had the full economic analysis been done in the first place, such production would have been retained domestically all along.

While my book, Outsourcing Information Security (Artech House, 2004), focused on IT (information technology) outsourcing, and was nonjudgmental with respect to offshoring, I did raise concerns that many indirect and less tangible costs were not being included in analyses leading to outsourcing/offshoring decisions. Among the risk categories that I highlighted were the loss of control, internal expertise and intellectual property and the expense and effort of retraining, which Fishman pointed out as problems now being encountered by GE in their reestablishment of manufacturing at Appliance Park in Kentucky.

Onshore outsourcing has many valid reasons relating to increased efficiency and the need for scarce, specialized expertise, and often has minimal impact on overall U.S. employment and spending. However, for offshoring you must add social costs, such as supporting huge numbers of displaced unemployed workers, and deduct the benefits of their consumer spending. The equation will then quickly switch in favor of onshoring. In part, this is also because global trading partners have not lived up to age-old economists’ expectations that foreign consumers and corporations would purchase more U.S. products and services as their standard of living improved.

The fact that business executives, such as GE CEOs Jack Welch and Jeffrey Immelt, were handsomely compensated for decisions that ultimately cost the country hundreds of billions of dollars, is but another example of “moral hazard,” which was exemplified by the lack of responsibility of banking and finance executives for the 2008 financial meltdown. Perhaps clawback of spoils emanating from these decisions is unrealistic, but it would certainly be reasonable.

One last point … There is a big difference between insourcing and onshoring, which is not apparent from the title of Fishman’s article. Onshoring, which is the crux of the article, is making increasing sense as relative direct human and energy costs are falling in the U.S. Insourcing is quite another matter. If the outsourcer is based in the U.S., the benefits of insourcing may be minimal from the corporate perspective and neutral with respect to the U.S. economy. It is important to account for this difference, since outsourcing is frequently the right decision, whereas offshoring often is not.”

More recently, in its January 19, 2012 Special Report on Outsourcing and Offshoring, with the title “Here, there and everywhere,” The Economist magazine elaborates on this phenomenon.

I find it particularly interesting that many companies, which are embarking on reshoring (or onshoring) and insourcing, are confronting many of the consequences from risks that I had warned about in my book Outsourcing Information Security, referenced in the letter, and these companies are about take on a whole new series of risks of which no one appears aware, or which they are not mentioning, if they are indeed aware of them.

In my recent book, Engineering Safe and Secure Software Systems (Artech House, 2012), I emphasize the importance of the types of intensive hazard risk analysis and verification and validation processes to which safety-critical systems are supposed to be subjected. It is also critical that adequate safety and security requirements are included at the start of projects.

The recent news reports about fuel leaks, battery fires and other issues relating to Boeing’s 787 Dreamliner have been particularly disturbing since the aviation industry supposedly has the gold standard when it comes to the development of safe and resilient airplanes … note that I didn’t include information security, since we probably won’t know the strength of protection against cyber attacks until one happens and is reported. I opined on reports that malware might have caused the fatal crash of a Spanair aircraft in my September 20, 2010 BlogInfoSec column, “The Infosec Game Has Changed – 154 Dead!” However the official final report on the causes of the crash placed most of the blame on the crew and, when it came to the computer systems, the finding was that the following was a contributory factor (see http://en.wikipedia.org/wiki/Spanair_Flight_5022 ):

“The absence of any warning of the incorrect take-off configuration because the TOWS [Take Off Warning System] did not work. It was not possible to determine conclusively why the TOWS system did not work.”

Well, that’s not particularly conclusive, is it? Whether the system malfunction or failure was unintentional (poor design, software bug, inadequate verification and validation) or deliberate (malware, insider malfeasance) is important information to enable the problem to be fixed or protected against in the future.

The Dreamliner is indeed a game changer but is disconcerting in terms of safety and resiliency. A principal concern is that the FAA (Federal Aviation Administration) delegated the testing of battery systems to the manufacturer (see The Wall Street Journal article “Crisis at Boeing” by Andy Pasztor and Jon Ostrower, January 18, 2013). Whatever happened to IV&V (INDEPENDENT verification and validation)? Furthermore, many physical control systems, which previously had considerable dependency on mechanical operation have been replaced with “fly by wire” fully electronic controls, which means that adequate electrical power must be available at all times. Hence the need for powerful state-of-the-art Lithium-ion batteries that provide more energy for a given battery weight than prior technologies.

However, what struck me, as someone with an information security background, is that the Dreamliner reportedly has brand new avionics software. This gives rise to many questions… Was an IV&V phase included in the software development lifecycle? Have security requirements and vulnerabilities been considered? Does the design of the software systems change relationships and interconnections between the less critical systems (such as the on-board entertainment systems) and highly critical flight control systems? If so, has the entire system been subjected to adequate security testing?

Furthermore (and this is also relevant to current aircraft), we must ask if the rush of transportation carriers (particularly aircraft, but also trains and road vehicles) to provide on-board Wi-Fi is opening up a new vector for attacks. The need for more extensive independent testing of the security of safety-critical systems is becoming even more important as the use of software systems intensifies. Are the testers keeping up, or are we just increasing risk without being aware that it is happening?

It is also apparently considered to be the go-to company for issues of what’s wrong with the world of cyber. This is supported by a quote by Richard Bejtlich, Mandiant’s chief security officer, in the February 2, 2013 issue of The Economist in the article “Cybersecurity: War on terabytes.” Here Bejtlich states that “No one in the United States is expected to provide for their own air defense. We have an army to repel a land invasion, so who is out there protecting the cyber lanes of control?  Nobody. It is a free for all.”

This is the well-known “tragedy of the commons” issue, where no one is willing to take responsibility for commonly used resources with the result that they are not protected and preserved, only to deteriorate to the extent that they can no longer support their original function. I have written about the topic, as it refers to cyber security, in previous BlogInfoSec columns.

I also wrote on the topic in the feature article “Cybersecurity and the Critical Infrastructure: Looking Beyond the Perimeter,” in the ISACA Information Systems Control Journal (May 2006), available at http://www.isaca.org/Journal/Past-Issues/2006/Volume-3/Pages/Cybersecurity-and-the-Critical-Infrastructure-Looking-Beyond-the-Perimeter1.aspx

Unfortunately, it does little good for even someone as high profile as Richard Bejtlich to point out the problem if there is no will to fix it. We’ve discussed this issue for a decade or more, yet are no closer to a resolution. This is where government can actually help. There needs to be accountability and liability insofar as the common resources of the Internet are concerned, particularly in regard to the securing of those resources. Organizations in the private sector are generally only interested in shielding themselves and their particular parts of the system. The U.S. government, while recognizing that some 70-80 percent of the country’s critical infrastructure is in private hands, is tentative at best in making the necessary moves to secure the commons, preferring to assign its responsibility to some nebulous public-private collaborative effort. Well, it hasn’t happened up to now and is unlikely to happen in the near future until some definitive actions have been taken. The past decade has been wasted with pretentions that something is being done. Successive “cyber czars” have tried and failed.

And some of the fuzzy recommendations currently being offered are not likely to be effective either. For example, in his article “Confronting Cyber Barbary Pirates” on the Opinion page of the February 11, 2013 issue of The Wall Street Journal, L. Gordon Crovitz writes: “It will take decisive action by Washington to deter rogue governments from breaching digital networks to read email, steal corporate information or identify news sources.” Because of the difficulty of identifying the definite source of an attack and because many sources are not nation states, it is hard to see how deterrence will work. And what kind of action needs to be taken? No, putting one’s hopes on deterrence will only disappoint. We need to resort to avoidance, e.g., not making critical sensitive data available from remote locations, and prevention, i.e., not allowing access to sensitive applications and data by questionable individuals. Yet even these approaches won’t work unless liability and responsibility are appropriately assigned and accepted.

Some commentators suggested that the dire warnings were overblown as they believed the Y2K warnings to have been. However, I don’t know of any computer programs that are based on the Mayan calendar, nor was there a multibillion dollar effort to remediate any such software if it did exist.

Having lived through Y2K mitigation efforts and having seen actual events occur, but not publicized, from the vantage point of the U.S. government’s command center, I can vouch for the reality of the Y2K threat and the superb efforts of those who mitigated the risks. There was no comparison. For the more recent prediction of TEOTWAWKI (the end of the world as we know it), there were no remediation efforts since no one knew what might actually happen. Even sending Bruce Willis up in a spaceship to destroy an incoming asteroid was not contemplated, although that is something that we should probably think about setting up, particularly if you realize how close to the Earth Asteroid 2012 DA14 will pass on February 15, 2013. From a small item “Close Shave” by Christopher Kaeser on page A14 (coincidence?) of The Wall Street Journal of January 2, 2013, you will discover that this asteroid will actually pass within 21,500 miles of this planet and that, if it had hit, the energy generated from the impact would have been 2.4 megatons or 120 times greater than the atomic bomb dropped on Hiroshima. That sounds pretty cataclysmic to me.

Just so you know what might have happened if the Y2K remediation hadn’t been done, watch the video “The Onion’s Extremely Accurate History of the Internet, Part 4: Y2k – A Civilization Rises From The Ashes” available at  http://screen.yahoo.com/onions-extremely-accurate-history-internet-005604031.html;_ylt=Arg879T4H22bLhBT5UbH1uxlnkQv;_ylu=X3oDMTNjN3UzZW01BG1pdANSZWxhdGVkIFZpZGVvcyBMb25nIGxpc3QgVVBQIDIEcGtnAzk5N2JkYTMwLTM4ZjUtMTFlMi04MWMxLTA4MDAyMDBjOWE2NgRwb3MDMQRzZWMDcmVsYXRlZF92aWRlb3NfY2EEdmVyAw–;_ylg=X3oDMTFoOTlpZTNlBGludGwDdXMEbGFuZwNlbi11cwRwc3RhaWQDBHBzdGNhdAMEcHQDdmlkLWdhbGxlcnk-;_ylv=3

There are still many who believe that the Y2K impending disaster was an overblown hoax perpetrated by consultants looking to generate business based on fear. It wasn’t a hoax. It was real. And it was one of the few cases where IT folks all over the world collaborated on working on a solution. It is among the finest examples of multinational cooperation, even though it was motivated by fear of catastrophe. Would that we could be prescient enough to anticipate and avert other natural and man-made disasters. The next time someone tells you that Y2K was a non-event, check their credentials. Did they actually work on the problem? If not, they have no basis for their assertions.