Who’s Minding the Store?

Before I could enjoy my Father’s Day brunch this past weekend, I found myself with a list of things to do around the house – cleaning out the garage, vacuuming the car, replacing our mailbox which “someone” in my family (not me) ran over. The latter of these tasks, of course, required that I go out and purchase some tools and supplies – a new post, new box, numbers for the box and a post digger – to get the job done.
My first stop in obtaining the necessary equipment, as always, was my local hardware store. I’m a huge proponent of buying things at local businesses rather than going out to the chain stores. I usually find the more local the store, the more helpful they are.
A similar theme, only from the “provider” point of view, is becoming pervasive among corporations when it comes to making applications available to their employees. Companies are “keeping it local” when it comes to making apps available. As InfoWorld’s app development guru, Paul Krill, points out:
“Companies developing their own custom applications, for example, do not want to make their intellectual property available in a commercial app store, so they set up their own.”
And who could blame them? With “Bring Your Own Device” (i.e., BYOD) one of the driving forces behind companies opening their own, proprietary app stores, organizations need to be certain that their customized apps do not wind up in the hands of those outside the company and they must be sure that the apps being downloaded by employees to access company files can be trusted.
With public app stores of today, that’s not always the case.
Buyer Beware
It’s little wonder companies want to keep their app stores close to the vest and their employees should actually be thankful for that move. If the news over the past 18 months about public app stores has shows us anything it’s that the quality of the available applications doesn’t always meet the highest standards for structural…and that’s being kind.
Take the Android app store for example. There are those who openly question if Google has any application software quality standards that need to be met before being offered in Android Market. Google would cite this laissez faire attitude as being part of its open source nature, but the old adage of programming – “Garbage in, garbage out” – should somehow apply to offering mobile apps in Android Market.
Even Apple, which posts a list of application standards for developers to use if they want to post an application to the App Store, has its issues with applications, but they see fewer of them. Why? Because their example of having a set of standards — and perhaps even a certification process —in place helps ensure structural quality and curbs the availability of malware in app stores.
Start at the Top
When it comes to application software quality, there is plenty of responsibility to be shared at each of level of mobile application distribution, and that’s a big reason why businesses are right in opening their own app stores for employees. Under their control, they can have oversight over the structural quality of the apps being offered and those who handle them – from those who develop the apps to those who administer the app store.
After all, responsibility for the structural quality of application software being offered rightly should begin at the top. The CIO or IT Director needs to establish a set of software quality standards for the apps being made available and then ensure any application that is offered meets those standards. This will help curb new issues and prevent vulnerabilities from older versions creeping into the new versions built on top of them.
Should companies fail to provide the necessary oversight for their app stores, they place their entire operation at risk because not taking responsibility for structural quality through a corporate app store is the same as nobody minding the store.

Hey Agile: Good Enough Ain’t Good Enough

As a writer, I frequently go back and review pieces I’ve written over time. When I do, I’d like to think that I’ll be happy and satisfied with each and every article, announcement, blog or brochure.
The truth is, however, that I seldom find that I’m patting myself on the back for a job well done…and I’m not talking about just typos. More often than not, somewhere within the piece I’ve written there is a paragraph, sentence, phrase or word that makes me wince and wish I’d taken a different approach or just worded things differently.
So I’m not perfect; that’s no newsflash (just ask the folks I work with…but don’t ask my wife unless you want an entire litany of my foibles). However, as a writer and blogger I can afford to produce something that’s “good enough” for publication. This was especially true when I was covering breaking news and writing under deadlines for a daily newspaper. What gets me is that there are those in the Tech industry who actually believe that good enough is good enough when it comes to application software.
Are you kidding me?
Technology Shouldn’t Imitate Art
We frequently hear those in industry lament that today’s workers take no pride in their jobs. They ignore the call for quality in an effort to meet quotas that bring them bonuses. It seems some in the Tech industry similarly see speed and quantity as the more important factors in developing software.
Recently, Andy Beal, CEO of social media monitoring tools vendor Trackur, posted an item on the American Express Open Forum in which he offers, “5 Reasons Why Being Agile Is More Important Than Being Perfect.” He introduces his argument by citing filmmaker John Lasseter, who says, “We don’t actually finish our films, we release them.”
In other words, Lasseter recognizes that with art you can go on forever making edits, reshooting and tweaking things; it will never reach a level of perfection in your mind or anyone else’s for that matter. In art – be it film, music or writing – good enough can be good enough. Heck, even after putting off his 1975 release of “Born to Run” to get every song on that album “perfect,” Bruce Springsteen to this day tweaks the tunes he plays from that album to make them “better” for that specific time and place.
But when it comes to application software – and mission critical software in particular – how can good enough be good enough? “Good enough” is what results in malfunctions. “Good enough” is what causes outages. “Good enough” is what leaves undetected the vulnerabilities from old versions of software that wind up being gateways for hackers who exploit them to steal sensitive data files.
And They’re Off…
Right from the start, Beal’s argument of why being agile is more important than perfection falls flat. His first point – speed wins – is hollow and even he attempts to back off from it. He posits that the first to market gains market share and customers, but he qualifies this by saying “you don’t want to be sloppy.” Well, therein lies the problem. Invariably, pushing application software to achieve arbitrary deadlines results in shortcuts being taken and, in too many cases, sloppy software. Sorry, but speed doesn’t win; speed kills.
Beal also tries to make the point that being agile – which he seems to equate with being fast (I equate it with being adept and adroit) – energizes employees and customers. What he seems to fail to take into account, however, is how that energy fades quickly and turns to disdain if the product that is rushed out the door winds up failing in some way. How “energized” are the IT teams at Sony, Sega, Citigroup, the London Stock Exchange, the Department of Defense or any of the other organizations that suffered some form of IT failure last year? How energized are their customers? I know Sony is “energized” to the point of 55 class action lawsuits and nearly $200 million in reparations.
Striving for Perfection
While I do believe speed kills, I also am not so jaded as to believe that true perfection can be reached. As Salvador Dali said, “Have no fear of perfection – you’ll never reach it.” But that doesn’t mean you don’t at least try to achieve it.
Beal also points out that ultimate perfection is not achievable. He notes that those companies that continue to tinker with application software run the risk of being beaten to market by a competitor that could, perhaps, launch a similar product that costs less and works better. But should software that is knowingly not up to snuff in terms of structural quality be released just to be first? I don’t think so. In fact, I believe author Francis J. Kong said it best, “The early bird catches the worm but the second mouse gets the cheese.”
Just because software can’t be perfect, that does not mean speed should undermine the effort to make it as close to perfect as possible.
There’s no reason why agile needs to settle for “good enough.” By taking the time to employ something like automated analysis and measurement to provide visibility into the application software and identify structural quality issues during the build process, agile developers will be more likely to correct issues while they are still relatively simple to fix and optimize the structural quality of the software. Optimal quality software makes for happy customers, not to mention more uptime, fewer headaches and lower technical debt because post-deployment problems should be few and far between.
That’s all for now…I hope it was “good enough.”

Days of Auld Lang Syne Best Not Be Forgot

Should old acquaintance be forgot, and never brought to mind?
Should old acquaintance be forgot, and days of auld lang syne?
Yes, many of us will find ourselves this weekend sipping champagne and singing the familiar lyrics of this centuries-old tune that has become as synonymous with New Year’s Eve as resolutions and the ball dropping in New York’s Times Square. But in a year when we saw one major outage, malfunction and security breach after another befall organizations that rely upon technology, we should heed a lesson from these verses.
2011: A Tech Odyssey
Easily the best-known tech issue of the year happened at Sony Corporation, which, in a span of four months, was victimized by more than a dozen hack attacks, most of them at the hands of the LulzSec group, and nearly all of them via SQL Injection. In all, Sony saw its hackers gain access to more than 100 million customer data files. So massive were the breaches that even Sony’s insurance company refused to pay off on its losses stemming from 55 class action lawsuits and hits to its operating profits to the tune of $178 million.
But Sony while Sony suffered the largest security breach, it was not the largest company to own up to problems with its technology. As usual, that spot was reserved for Microsoft.
First came April’s Patch Tuesday, which saw Microsoft release a record-tying 17 bulletins that patched a record 64 vulnerabilities, 15 more than the previous largest-ever set in October 2010. Equally significant to the total were the “critical bulletins,” which included security patches affecting Windows XP, Vista and Windows 7, and at least some of which affected the kernel. The second was November’s Patch Tuesday, which witnessed Microsoft craftily avoiding an attempt to patch a zero-day vulnerability used in the Duqu malware attacks that allowed hackers to run arbitrary code in kernel mode. Microsoft instead offered a work-around for the issue.
Microsoft and Sony were far from alone this year. Game maker SEGA and security vendor RSA were also among those who were dinged by hack attacks. Meanwhile, software malfunctions, vulnerabilities and product recalls due to software structural issues befell Dropbox, Google and even Apple this year.
Financial Disarray
Financial organizations were hit hard this year. On the morning of February 25, we learned the London Stock Exchange had been forced to halt trading on its main market due to a technical fault in its barely two-week-old MilleniumIT trading system.  Despite having been tested prior to its implementation, the reason for the failure of the relatively new system was “algorithms.”
But the LSE was not alone. That same month, Nasdaq OMX Group confirmed that its servers had been breached, and suspicious files found on servers associated with the Web-based collaboration and communications tool for senior executives and board members to share confidential information. Over the succeeding two weeks, Euronext, Borsa Italiana (bought by the LSE in 2007) and the Australian Stock Exchange had all suffered outages due to technical flaws. A few days later, Bank of America joined the exchanges when it suffered a major outage in its ATM network. And lest anyone think lightning does not strike twice, later in the year Bank of America’s website was taken down by a “denial of service” attack.
And the issues did not end there. The Financial world had barely caught its breath over the flurry of outages in the first quarter when Chase and JP Morgan warned customers of a potential breach of security. They were followed shortly thereafter in May by Citigroup, which announced its North American cards division had fallen victim to hackers who had finagled access to names and information of more than 200,000 customers.
Man at the Top
Application failures at the government level were perhaps this year’s biggest surprise. The surprise was not because of their existence – the U.S. government is known to be one of the biggest targets for hackers worldwide and is even targeted by foreign governments – but because of the number to which they owned up.
The most serious among them was a data breach at a Pentagon defense contractor in which 24,000 sensitive files were stolen by a hacker backed by an unidentified foreign power. The attack, which took place in March, was not revealed until July and even then only under the auspices of announcing a plan to better prepare the government and the military for cyber terrorism.
This revelation was followed later in the year by a breach at Pacific Northwest National Laboratory, a Department of Energy contractor, over Independence Day weekend and then news of the Air Force’s new drone being infected by a computer virus. And these were just a few of the literally tens of thousands of cyber attacks the government has had to fend off in the past year.
…And the Beat Goes On
I would like to say the list ends there, but there were also airlines, railways, medical devices and health care institutions that met with application failures that led to malfunctions and outages this year. Heck, they even found a software vulnerability that could allow someone to shut off a person’s pacemaker!
The sad part about nearly all, if not all of these outages, malfunctions and breaches is that their roots were located not with an outside source – no, the outside source was merely the catalyst for disaster. All of these issues had in common a structural flaw somewhere down in the bowels of the application that had gone undetected.
Perhaps it was part of legacy code that once was valid, but after multiple generations is no longer a solid piece of work. Or maybe it was just a badly written piece of code that got passed over because it didn’t bother anything in the testing phases.
Whatever the reason this structural quality error happened, it shouldn’t have. Hopefully in 2012, companies will look back on all the problems in 2011 and realize that they need to increase the structural analysis of their application software to ensure they won’t be the next Sony, SEGA, Citigroup, et al.
Should old acquaintance be forgot and never brought to mind? HELL NO!
For as Sir Edmund Burke once said, “Those who do not learn from history are condemned to repeat it.”

The Dark Side of the Limelight

Marketers frequently discuss the benefits of market leadership – the ability to charge premium pricing, attract the best talent, retain customers – and the like. Today, there is a new metric: if you develop operating systems, applications and other kinds of software, if someone isn’t trying to hack your work, then you must not be a market leader.
Android developers are discovering the downside of their new-found popularity. McAfee’s Third Quarter Threats Report, notes that Android malware samples by quarter rose from just over 20 million in Q1 2011 to approximately 60 million in Q2 and more than 90 million in Q3. Oh, that my stock portfolio should show such growth!
There are several layers of interesting information here, covered well by GigaOm’s Ryan Kim in August. First, that hackers are shifting their focus to mobile platforms – clearly where the action is today in terms of innovation and rapid subscriber growth. In addition, Android’s app store lacks the strong oversight that reduces malware threats in Apple’s App Store, and allows users to sideload apps.
Earlier this month, Microsoft urged Android owners to share their Android-related malware issues, entering those who responded into a contest to win a new Nokia Windows smart phone. Smart ploy or cheap gimmick? Well, with just 2 percent of the U.S. smartphone market, Microsoft has little to lose.
Eric Chien, Symantec’s Technical Director of Security Response, notes in an October white paper, seven schemes attackers often use malware for against Android subscribers:

Premium Rate Number Billing- Attackers set up and register premium-rate numbers, which can charge up to $50 per message, the revenues split among the attacker, carrier and the SMS aggregator.  The attacker then creates an app and releases it on the Android market. Users download the app, which periodically sends SMS messages to the premium-rate number.
Spyware – Attackers will take advantage of the many Android apps that allow someone to track smart device users. Attackers purchase one of these apps and then gain physical access to the phone.  The attacker doesn’t directly make money in this approach, but the spyware vendor does.
Search Engine Poisoning – Many search engines rank or recommend websites by tracking user visit rates. Smart device users may customize this monitoring based on their interests. Attackers will set up malicious apps that initiate multiple requests to these sites, poisoning the hit rates monitored by the search engines. By raising their search rank, attackers can generate revenue through pay-per-view or pay-per click ads.
Pay-per-Click – Many services, such as advertising networks, pay every time an affiliate or partner site refers a user to a website. Attackers will use malicious apps to generate artificial visits and receive a few cents per click.
Pay-per-Install – Legitimate distribution marketplaces will host apps for download and charge vendors based on the number of downloads and installs by subscribers. To date, the report notes Symantec has not seen attackers use pay-per-install schemes to generate revenue, but it has see threats that install new applications.
Adware – Many mobile advertising networks pay content providers by view and click, which can average $1-2 per thousand impressions. Attackers have repackaged or cloned popular legitimate games and included a mobile ad library registered to the attacker. Every time the app is used and ads are displayed, the attacker generates money.
mTAN Stealing – When using an online bank account, some banks require additional credentials to be sent out-of-band to avoid man-in-the-middle attacks. This can sometime include the bank sending a random Transaction Authentication Number (mTAN), to a previously registered mobile phone number. Malware must be installed on this phone to receive this number.

As Android popularity continues to grow, attackers will continuously find new ways to monetize malware schemes. This is why Google needs to work in concert with Android developers to combat the malicious efforts of these attackers. Google should establish requirements for higher quality and force Android Market to scrutinize applications more closely for structural quality – at all would be a nice start – before making an application available.
As for the developers themselves –the legitimate ones at least – would likely welcome such scrutiny. They should embrace such a vetting process as a sort of third-party corroboration of their application’s security and structural quality, which could be a competitive differentiator.
By establishing standards for application software structural quality, mobile app stores like Android Market would certainly foster a growth of application integrity among developers by frequently assessing and improving how their code is designed and implemented.
Granted, quality software won’t absolutely prevent attackers from plying their malicious trade, but much like the car thief who targets unlocked cars first, it may slow them down enough that they find another app to hack in place of yours.

Going Gaga over Google

Talk about the ultimate case of “Buyer beware!”
It was recently reported that within the next couple months the meteoric rise of Android Market is all but certain to overtake the iPhone App Store in terms of the number of applications offered. Taken on face value, this should come as little surprise to anyone.
With the wide slate of devices on which Android can operate, its app store should have a much wider customer base than does iPhone, whose apps can run on only one type of device – the iPhone. Add to that the slowing of App Store downloads experienced by iPhone over the last few months – perhaps due to Android infiltration in the “touch phone” market or perhaps due to iPhone being out there awhile so people have what they want – and the fact that Android’s app store is about to overtake iPhone’s makes sense.
What doesn’t make sense is that all this continues to happen under the shadow of Google’s extremely lax criteria regarding the quality of applications being made available in its Android Market.
Standards … Wherefore Art Thou?

Wait a second…did I just call Google’s criteria for Android Market lax? That might be giving it too much credit!
There are those who openly question if Google has any application software quality standards that need to be met before being offered in Android Market. Google would cite this laissez faire attitude as being part of its open source nature, but the old adage of programming – “Garbage in, garbage out” – should somehow apply to offering mobile apps in Android Market.
By contrast, Apple has a well-known process for posting applications to the iPhone App Store. It even posts a list of application standards for developers to use if they want to post an application to the App Store. (NOTE: This author is not promoting iPhone over Android. In fact, this author is still a BlackBerry owner.)
Granted, Android’s popularity is the number one reason malware maniacs have made it a prime target, but the near complete lack of review of applications posted to Android Market is also a major contributing factor.
A set of standards — and perhaps even a certification process — must be put in place to curb the availability of malware in app stores.
Structurally Sound, Malware Free
Because so much of business today is conducted on mobile devices that access enterprise networks, an independent third-party assessment program is needed to ensure that applications being accessed via mobile are safe, structurally sound and efficient. The same holds true for consumer apps, such as games and ads.
When it comes to application software quality, there is plenty of responsibility to be shared at each of level of mobile application distribution. The platform owner, Google; the app store, Android Market; and the mobile developers themselves all need to do their parts to ensure quality.
Responsibility rightly should begin at the top. Google needs to take steps to ensure that the software that goes into the devices – for operational purposes or as pre-loaded applications – is of optimal structural quality. It needs to apply some measure of automated analysis and measurement to its own OS to prevent issues and vulnerabilities from older versions creeping into the new versions built on top of them.
The current problem is that Google doesn’t ask much (read that as “anything”) of their developers when it comes to ensuring software security and quality. Were they to demand higher quality, Android Market would need to scrutinize applications more closely – or in Android’s case, at all – before making an application available.
As for the developers themselves –the legitimate ones at least – would likely welcome such scrutiny. They should embrace such a vetting process as a sort of third-party corroboration of their application’s security and quality, which could be a competitive differentiator.
Unfortunately, until Google, Android Market and Android application developers do something to adopt minimum software quality standards, those “going gaga over Google” will continue to find themselves driven gaga trying to fend off malware.

Mobile App Development: Many Questions, Few Answers

Usage of Google’s Android mobile platform is growing at an exponential rate; unfortunately, so is the malware being developed to attack it.
On Monday came the news of the Malicious Mobile Threats Report 2010/2011, released last week by the Juniper Networks Global Threat Center, that reveals a frightening statistic: since the summer of 2010, “Android malware has surged 400 percent.” What is to blame? According to eWEEK’s Fahmida Y. Rashid, the report cites user naiveté and general nonchalance as a major reason for malware developers putting a big ‘bulls-eye’ on the Android platform.
All of this begs the question: As Android sales continue to rise at exponential rates and overtake sales of all other smartphone platforms, at what point does someone tell Google it needs to do a better job of policing its app store?
Mobile Development Questions
Interestingly enough, these same questions came up in an article posted on CIO.com not too long ago. In an article titled “8 Security Questions to Ask Before Building Mobile Apps,” John Dickson notes that development of mobile applications has exploded over the last few years as enterprises attempt to get in on the popularity of all types of mobile devices – iPhone, Android and BlackBerry. Of the development rush, he urges:
“Business line managers need to make sure that marketing and IT managers who are building mobile applications are protecting customer data and not inadvertently opening up unexpected security holes for outside attackers.”
Dickson proceeds to question how mobile applications work within an enterprise setting, how they differ from enterprise applications and whether those developing mobile applications have the skills to create them for an enterprise (he actually believes many do not). However, he wraps his article with two very interesting questions, neither of which he answers in full:

What organization (enterprise, device provider, mobile OS provider) is responsible for security?
What development approaches are in place to build more secure mobile applications?

So exactly WHO should be responsible for security and what can be done to build more secure applications?
Mobile Development Answers Start at the Top

There seem to be three distinct groups involved in the management and administration of mobile applications – the platform owners (Apple, Google, RIM, etc.), the app stores for each platform and the mobile developers themselves. When it comes to security, though, there is plenty of responsibility to be shared at each of these levels.
Responsibility should begin at the top. Apple, Google and RIM need to take steps to ensure that the software that goes into the devices – either for operational purposes or as pre-loaded applications – is 100% secure. Also, since each company manages its own device’s app stores, each should insist that an application meet minimum quality standards, in terms of both security and application software structural quality, before it can be listed in the app store. And finally, the developers themselves – the legitimate ones – need to take additional steps to ensure the security and quality of their applications.
I know what you’re thinking – this is “pie in the sky” thinking. Well, not entirely.
The current problem is that the various mobile platforms do not currently ask much of their developers when it comes to ensuring software security and quality. Were they to demand higher quality, app stores would need to scrutinize applications more closely – or in Android’s case, at all – before allowing an application to be listed.
In order to reach such a decision point, though, a set of software quality standards needs to be established – perhaps by the mobile platform vendors themselves – against which applications can be tested and certified. Then, by requiring mobile applications to pass through such an analysis and earn some form of certification to be listed in an app store, there would be a forced compliance of these minimum quality standards.
Unfortunately, until platform vendors, app stores and developers adopt a mobile certification program that ensures applications are safe to use, there will continue to be more questions than answers for mobile app development.

Certifiably Mobile

Earlier this month, Symantec released its Internet Security Threat Report for 2010, and much like other reports on the state of software security for last year it showed significant increases in malware and other threats to application software and websites. In all, Symantec reported 286 million new Internet threats in 2010.
Most surprising was the rise in Web attacks from 2009 to 2010. Symantec reported a 93% jump in web-based attacks year-over-year.
On the mobile side, Fahmida Y. Rashid at eWEEK reported that Symantec also saw a considerable increase in vulnerabilities in mobile operations systems in 2010. Last year saw 163 vulnerabilities compared to 115 in 2009, an increase of 42%. Rashid is quick to add that while the total number of mobile vulnerabilities paled in comparison to web-based attacks, Symantec predicted that the number would continue to increase at a very high rate in 2011.
Much Mobile Malware
What we’ve seen so far in 2011 bears out this prediction. We have already seen one story after another about mobile malware grabbing headlines, many of them directly related to the Android operating system. And these malware applications have been showing up in quite rapid succession.
But is the problem the operating system, the applications or the app store policies that Google practices?
Perhaps the answer to that lies in Kenneth van Wyk’s comments at Computerworld where he goes so far as to call these appearances of malware in the Android App Store “inevitable.” He says, “The recent spate of malware-infested apps found in the Android Market illustrates the point. Mistakes are going to happen, even if our app providers undertake reasonable precautions in guarding their stores.”
At the crux of the problem, van Wyk points to Google’s loose review process for allowing applications to be posted to its app store. He notes that Apple has a team of reviewers reviewing submissions for its app store. As for Google, he points out, “the Android Market is far less rigorous in its review processes. That’s being charitable.”
Van Wyk does say that even Apple’s app store has its share of malware issues, “Mistakes are going to happen,” he says. He then provides tips for mobile device users about how to protect themselves and their devices by being more aware of what they are downloading.
No kidding.
With all of our technology and all the parties involved with mobile applications – from the developer, to the reviewers at the app store to the buyers – there must be a better strategy for preventing a spate of malware from affecting mobile devices than a combination of “buyer beware” and “every man for himself.”
SaaSy Certification
Because so much of business today is conducted on mobile devices that access enterprise networks, an independent third-party assessment program is needed to ensure that applications being accessed via mobile are safe, structurally sound and efficient.  The same holds true for consumer apps, such as games and ads.
It is time for the entire mobile application software community to organize and adopt a certification process that can provide independent accreditation of mobile applications. This process should be simple to access and relatively inexpensive, like in a Cloud-based portal . Such a portal would automatically analyze and measure the code and provide feedback on software size and health, based on industry norms, standards and best practices. This would allow mobile software developers to seek and provide to consumers a piece of third-party corroboration that their applications are robust and free of malware.
If legitimate developers were to seek such mobile application certification, and if app stores were to require it, buyers would no longer have to beware because rather than “every man for himself,” mobile malware prevention would be a case of “all for one, and one for all.”