26
Feb

Online businesses looks to be on course for a negative event of even greater magnitude — stay tuned

2-Color-Design-Hi-Res-100px-widthIt is one thing to lose something of great value while covered by a comprehensive insurance policy, and quite another to be in the same position, albeit without the coverage.

So adding the insurance policy looks to be a no-brainer, right? Not so fast. According to an article titled Cyber attack risk requires $1bn of insurance cover, companies warned (http://www NULL.ft NULL.com/intl/cms/s/0/61880f7a-b3a7-11e4-a6c1-00144feab7de NULL.html?siteedition=intl#axzz3SrQZqbSm), written by Gina Chon and published on Thursday, January 26, 2015 by the Financial Times, businesses are not only finding a lot of obstacles on their way towards securing the extent of insurance coverage they need to cover online commerce, but (and this is even more worrisome) are also exhibiting a lot of reluctance to even make the effort. If we are looking at a wave of complacency, then perhaps we are looking at a major negative event with enormous financial impact all around in the making.

Back in October 13, 2013 we published a post to this blog titled Online Security Problems are too Pressing for the Public to Continue to Ignore. The position I have always taken on topics like the one Chon treats in her article for the FT is as follows:

  • the “mono protocol” data communications world we have, perhaps inadvertently, created by vigorously pushing further expansion of markup language code at the application layer with Ethernet over TCP/IP as the underlying pipe is very very dangerous. The old world of multiple data protocols running across wide area networks made a lot more sense and was, inherently, safer

But my position, at present, is “so be it”. The internet, for better or worse, as it is presently technically constructed is here to stay. The question ought to be how do we get this “genie back in the bottle” and mitigate the risks associated with doing business online.

Apparently businesses are not willing to take the steps required to accomplish this critically important step. Underwriters seem not to want to handle the risk and the insured are not willing to pay the cost for coverage. This is a potentially dangerous condition. One would hope all of the parties involved will see their way through to a mutually satisfactory conclusion. The sooner the better.

Ira Michael Blonder

© IMB Enterprises, Inc. & Ira Michael Blonder, 2015 All Rights Reserved

26
Aug

Smart Machines May Prove to be a Bonanza for Risk Underwriters and Automation Security ISVs

Automobile manufacturers have publicly expressed serious determination to quickly add more features to permit drivers to engage in personal computing activities like reading email, chatting with colleagues, and more. But all of this may not, after all, be a good thing. Nick Bilton of the New York Times published a post to the Bits blog, Disruptions: As New Targets for Hackers, Your Car and Your House (http://bits NULL.blogs NULL.nytimes NULL.com/2013/08/11/taking-over-cars-and-homes-remotely/?ref=technology). This post recounts some demonstrations presented at this year’s Defcon held in Las Vegas: “Imagine driving on the freeway at 60 miles per hour and your car suddenly screeches to a halt, causing a pileup that injures dozens of people. Now imagine you had absolutely nothing to do with the accident because your car was taken over by hackers.” (quoted from Mr. Bilton’s article as posted to the New York Times’ website, a link to which has been provided above”.

Clearly there is substantial cause for concern if Ethernet data communications capabilities are added to cars without a set of security controls capable of successfully defending them from malicious cyber attack. Cars are moving vehicles, usually weighing in excess of a ton, or more. It does not take much of an imagination to envision the destruction a rogue automobile can wreak in any one of a voluminous set of ways, if controlled by individuals with nefarious intentions. We think automobile manufacturers must completely verif the effectiveness of security controls purported to be capable of protecting smart cars from hackers, and, further, certify them prior to adding these features to cars.

The positive side to all of this, if there is one, is a substantial market for ISVs with security systems for precisely this type of application. While we are not in touch with any of these businesses, we think some excellent candidates can likely be found in the aerospace industry.

There is also an excellent market emerging for insurance underwriters willing to provide products for the cyber terror market. The kind of frightening event Nick Biltin recounts in his post can be a bonanza for risk insurers willing to service these markets.

Ira Michael Blonder (https://plus NULL.google NULL.com/108970003169613491972/posts?tab=XX?rel=author)

© IMB Enterprises, Inc. & Ira Michael Blonder, 2013 All Rights Reserved

3
May

Executive Changes at Intel May Signal Their Future Chip Platform Efforts

In an article titled Intel’s CEO Pick Is Predictable, but Not Its No. 2 (http://online NULL.wsj NULL.com/article/SB10001424127887324766604578458650267324178 NULL.html?mod=WSJ_Tech_LEFTTopNews), published in the online edition of the Wall Street Journal on Friday, May 3, 2013, the authors, Don Clark and Joann S. Lublin, note the surprise of some Intel analysts at the selection of Renée James as the new President of Intel. We share their surprise.

Ms. James’ major achievements include her instrumental roles in the acquisitions of Wind River Systems and McAfee. Neither of these businesses have anything to do with chips, or firmware. So why Ms. James for the position of President?

We can’t help but interpret this executive appointment as a signal of a change in likely market direction for Intel, going forward. We think the board is tacitly throwing in the towel, at least for now, on seizing any type of position as a contender to ARM in the small, smart mobile device markets. Sure, Intel made many attempts over the years to take ground in these markets and failed. But now failure appears to be maturing into an outright retreat.

If we’re right, it will likely be much harder for companies depending on Intel’s chips (Microsoft and its OEMs) to win any market share of any significance from the ARM crowd. Intel’s innovations (like the current Atom processor) will continue to fail to meet some fundamental market requirements and leadership will remain largely in the hands of Android and Apple.

It’s nevertheless fascinating to watch an enormous business like Intel implement a horizontal product strategy. Diversification certainly makes sense from a risk management perspective. With its cash on hand, Intel can afford to buy its way into markets. The sales cycle patterns of McAfee and Wind River Systems are likely very different from those of Intel’s core chip business. Perhaps the board selected Ms. James for her ability to help the business continue its diversification strategy.

A healthy Intel, feeding off of subsidiaries like McAfee and Wind River Systems, can certainly take the time to think harder about how to re-enter mobile markets with better technology.

Ira Michael Blonder (https://plus NULL.google NULL.com/108970003169613491972/posts?tab=XX?rel=author)

© IMB Enterprises, Inc. & Ira Michael Blonder, 2013 All Rights Reserved

21
Mar

Why Early Stage ISVs Should Plan on App Dev that Services Multiple Computing Platforms

Every business, regardless of size, must plan for managing risks. Some businesses consciously build a risk management strategy, while, for other businesses, the process appears to be unconscious, or even missing.

We think an important area of exposure for early stage ISVs can usually be found in their product development strategy. When we look at a product development plan, we ask about the computing surroundings around the tools and applications the business plans to produce. Is this software captivate to a specific computing platform, for example, Microsoft® Windows, of GNU/Linux? If the answer is yes, we usually attempt to learn more about the rationale behind the business’ decision to fully commit development efforts to one computing paradigm.

One needn’t look much further than the historical timeframe from late 2010 to present to note a radical shift in computing. Lots of business users are making radical changes in how they handle their daily computing tasks. Large ISVs, for their part, are contributing to the flux with new offers intended to support users doing what they used to do with desktop computers, but now with tablets, smart phones, or phablets.

A small ISV with one application on the market for MS Windows computing can, literally, plan on a very likely decline in revenue over the next few years as users continue to shift over to computing via other devices with their own operating systems and platforms.

How could this small ISV avoid the mess it might shortly find itself in? We think it makes sense to take core business capabilities and apply them over as wide a computing landscape as possible. If you build workflow tools for Oracle, or Microsoft products, you should explore opportunities to build workflow tools for Google Apps. By taking the steps required to open alternate markets you will provide your business with a defense should a worst case scenario arise. Better yet, write your applications in code that has been proven to be genuinely portable. It also makes sense to develop either a cloud SaaS for your solution, or a version of the solution that works with each of the browsers on the market today.

Ira Michael Blonder (https://plus NULL.google NULL.com/108970003169613491972/posts?tab=XX?rel=author)

© IMB Enterprises, Inc. & Ira Michael Blonder, 2013 All Rights Reserved

14
Feb

Does It Make Sense to Excise Risk Management from Software Development Methods?

This is a second annotation of an article, Send in the Tech Reinforcements (http://online NULL.wsj NULL.com/article/SB10001424127887323375204578272001161503898 NULL.html) authored by Arthur Herman and John Scott. We’re focusing here on the authors’ point that “the Pentagon relies on a bureaucratic review process that demands contractors anticipate and resolve problems in advance. Every software engineer, however, knows that’s not possible or even desirabled.” (quoted from Messrs Herman and Scott’s article, a link to which has been provided in this paragraph). We are also interested in a comment made further on in the article that “[l]earning by trial and error doesn’t work so well for aircraft carriers or Abrams tanks, but it is crucial for the development of effective software.” (ibid).

We think that the Pentagon process that’s got our authors’ attention, which they find hard to accomodate, is actually operational risk management for software development. In our opinion, the interest on the part of the Pentagon in implementing and exercising operational risk management in order to ” . . . anticipate and resolve problems in advance” is far more than merely a “bureaucratic review process”. (quotes are excerpted from the Messrs. Herman and Scott’s article). In fact, we think it is critically important for the welfare of our military personnel that this type of scrutiny be exercised over custom requirements for software. Regardless of whether specific software is intended for office computing use, or for use on the battlefield, any software application accessed by today’s desktop computers is potentially a trojan horse that could be maliciously exploited by enemies of our country or other individuals with nefarious intent.

To give the authors credit, perhaps their point is that the operational risk management methodology implemented by the Pentagon is ineffectual. If, in fact, the authors are attempting to make just such a point, then, perhaps we can be more agreeable to their point of view. However, by no means do we see how the Pentagon could safely adopt a policy that welcomes a “learning by trial and error” method of software development and still safeguard our military personnel.

Rather, we agree with the authors that attempts at managing the risk represented by custom software have been, evidently, somewhat clumsy on the part of the Pentagon, and, further, ineffectual as regards safeguarding our systems from malicious attack, despite substantial cost overruns. But we think all of this work and little progress points to a real need to rethink operational risk management policies and procedures for the actual task of developing software for military use in 2013. By no means, in our opinion, does it make sense to abandon the attempt altogether.

In the next post to this blog we will look at one last set of points made in this article.

Ira Michael Blonder (https://plus NULL.google NULL.com/108970003169613491972/posts?tab=XX?rel=author)

© IMB Enterprises, Inc. & Ira Michael Blonder, 2013 All Rights Reserved