Dan Griffin’s Blog » 2009

Dan Griffin's Blog

Comments on security, PKI, smart cards, cryptography, and entrepreneurship.

BlackHat highlights

July 31, 2009

The BlackHat security conference has been going on this week in Las Vegas. A good link for highlights is here. The full topic list is here.

Permalink | Comments (0)

One of the buzz words at the Microsoft Partner Conference last week was XRM. What does that mean? Harkening back to highschool algebra, the X is a variable that can stand for any word that you’d care to put in front of Relationship (or Resource) Management. Examples include Customer, Enterprise, Sales, Supplier, etc. This was specifically in the context of the Microsoft Dynamics CRM product, of course, although the concept is broader than that.

Why does it matter? The observation is that the same software tools that businesses use to establish and automate sales processes - such as MS Dynamics, Oracle, or Salesforce.com - have broader applicability. These tools are workflow engines that often can just as easily be used for point-of-sale as for supply chain management. In other words, they’re what software vendors like to call platforms, as opposed to just applications.

In the Microsoft world, XRM refers to the use of the Dynamics CRM product as a platform that offers record storage, customizable workflows, role separation, and scalable performance. An example of an XRM application is our Secure Sales Order System.

Generally, XRM implies a three-tier architecture, including a web- or desktop-based client application (the top tier) that has been customized and tuned for specific user scenarios. The second tier is Dynamics CRM, exposed to the client via XML web services. The bottom tier is Microsoft SQL Server. Finally, ideally, authentication and policies are integrated with Active Directory.

Permalink | Comments (0)

Demo video for Secure Sales Order System

Check it out here on YouTube.

What is the SSOS? In summary, a new solution from JW Secure that integrates with Microsoft Dynamics CRM.

In more detail, the purpose of the Secure Sales Order System is to track sales orders and to ensure that high-value approvals are made only by authorized personnel. The system has several notable benefits:

It uses biometric based authorization to increase auditing compliance and decrease fraud.
It uses a task-specific interface to increase efficiency and decrease errors.
It leverages existing technology investments made by your organization.

From a technical perspective, the Secure Sales Order System is a user-friendly (Windows Presentation Foundation based) application that provides sales order entry and approval. It integrates with Active Directory for user authentication, and it integrates with Microsoft Dynamics CRM for record storage and workflow management.

The key feature of the Secure Sales Order System is how it handles high-value order approvals. For orders exceeding a certain value threshold, not only must the approver be on an approval list, he or she must also provide a successful fingerprint scan in order to securely establish his or her identity. This multi-factor authorization approach is important for maintaining compliance with auditing requirements, as well as for fighting fraud.

Permalink | Comments (1)

Mobile Apps Should be Transactional

July 15, 2009

At the Microsoft Partner Conference this week, most of the talk about software vendor (ISV) scenarios for Windows Mobile has centered on non-browser-based applications. In other words, “thick” client applications running on the phone.

This irks me, because today’s businesses are rarely able to standardize on a single mobile platform for their users. There are going to be iPhones, Windows Mobiles, G-phones, Blackberrys, Palms, and Symbians, not to mention “feature phones” that may or may not even have a browser. So if a custom client application will meet the business need, great, but is the plan to port to each different platform? That’s an expensive approach, difficult to maintain, and not scalable.

To be sure, there are still good reasons for the custom client app approach. First and foremost, there are customer scenarios in which access to data may be required at times when the network isn’t available. For example, if I want to view crop yield information on my phone, but I’m in the middle of a field with no wireless and no 3G, I’m stuck if that data isn’t already present on the device.

Another example: I’m a salesman and I input a new order into our CRM system. However, it’s a large deal and requires the approval of my boss. Unfortunately, she’s travelling. Via a custom CRM client running on her phone, she can approve the deal, but I have to wait until she’s connected, checks for pending approvals, or gets notified via some mechanism that there’s an order pending.

None of this behavior is impossible to achieve with some combination of a browser, mobile email, and SMS, and that’s my point. For example, the sales order approval could be handled in an automated way by the CRM system: send an email to my boss with some relevant metrics to drive the decision. For example, what’s this customer’s credit limit, and would this deal cause it to be exceeded? Then, my boss can reply to the email with the text “Approve” or “Deny” and the CRM system will receive it and take the appropriate action.

Similarly for the first scenario: why not push the crop yield information periodically via email?

This way, there are no custom apps required: such a transaction-oriented solution works on any phone with email support. That’s a low bar, much more affordable, maintainable, and scalable.

Permalink | Comments (0)

Win 7, Chrome OS, Security

July 12, 2009

There can be no doubt that Google’s announcement last week, that its Chrome OS would ship late next year, was timed to distract from Microsoft’s expected announcement this week of Windows 7’s release to manufacturing (RTM). And even though any significant adoption of Chrome OS will take several years, Google’s announcement has proven to be a cleverly timed distraction in terms of internet buzz generation, causing tech writers and bloggers to spend page space on Chrome OS that might otherwise have been spent on the new Windows release.

BusinessWeek makes the point that Google’s announcement also serves as a reminder to the IT community – and to Microsoft – that computing is moving into the cloud. For certain types of users, the browser, and the latest generation of online productivity and social networking applications, is sufficient. The industry seems to be moving toward a world where very few “thick” client applications are needed, since comparable functionality will be available online.

On the other hand, I think we’re pretty far from that. How many businesses use online point-of-sale, office/productivity, or accounting apps for core operations? How many run SAP or Oracle in the cloud? Not too many, seems to me. And while I perceive great pressure among customers to move in that direction – with the anticipated cheaper licensing, deployment, and maintenance costs – there are some significant barriers.

The foremost such barrier is confidentiality. Licensing issues aside, SAP and Oracle aren’t run in the cloud because the technology, regulations, and laws aren’t yet in place for that sensitive business-critical data to live offsite. And the same applies to many every-day office apps and the data consumed by them. Can you imagine a public company storing next quarter’s sales forecasts on a shared virtual hard drive, in some unknown physical location, owned and operated by another company? I can’t, although I admit that the equation is very different for smaller firms (for example, the customers of salesforce.com have clearly faced this tradeoff and decided that offsite storage of sensitive data is an acceptable risk).

Indeed, a lot of the buzz around Chrome OS has centered on its anticipated utility for and uptake by internet start-ups. This is in fact highly likely, if Chrome OS allows “thick client” applications (for example, Eclipse) to be installed and run, and if those apps already run on Linux.

But will Chrome OS be more secure than, say, the more locked-down versions of BSD are today? No, especially if Chrome OS isn’t based on BSD. (As an aside, that point is unclear to me, since I thought at least some of Google’s core operations used BSD, and it would thus be the logical choice for a supposedly very secure new OS. But the announcements have all said Linux, which in theory implies non-BSD plumbing.)

Will Chrome OS be less susceptible to viruses than Windows 7? Almost certainly; hackers go after the highest value targets.

But that’s missing the point, especially since Chrome OS is supposedly all about the browser experience (and the paranoid have always had more secure, albeit fringe, options – see reference to BSD, above). After all, who’s going to use a browser that doesn’t support Flash and JavaScript, even though both technologies are notorious for security bugs (regardless of the platform)? And if Google has a technology that dramatically reduces user susceptibility to phishing attacks, they should (and probably would) release it right now, not wait until next year. Otherwise, from the perspective of the browser-based attack surface afforded by the typical web user, it’s not clear what significant improvements are being made by any vendor, let alone Google.

Permalink | Comments (0)

Getting ASP.NET ReportViewer working on IIS

July 5, 2009

Been playing around with building a “Key Performance Indicators” dashboard, based on QuickBooks data, accessible from a phone with a browser (mine’s a Motorola Q with WM6). My first attempt has been to use the ASP.NET ReportViewer control. But when I attempted to deploy the page to IIS instead of the Visual Studio development web server (in order to make the page accessible to my tethered phone; http://localhost isn’t routable), I hit two problems.

Solutions are here for posterity:

You need to install the latest ReportViewer redistributable.
You need to either use the classic app pool in IIS, or setup a custom managed handler for the reporting control. Info is here.

Permalink | Comments (1)

iPhone application business model

July 2, 2009

I’ve been doing some research into this lately, especially in anticipation of contrasting it to similar opportunities that may be offered by the upcoming Windows Marketplace for Mobile (http://www.microsoft.com/presspass/press/2009/feb09/02-16MWCPR.mspx).

Regarding the iPhone, it’s certainly got buzz in its favor. And as of Q1 CY09, Apple had sold 21 million iPhones.

On the other hand, Microsoft announced that 20 million Windows Mobile devices sold in 2008 alone. However, unfortunately for the independent software makers, what’s missing in the Microsoft case is a sales channel like the iPhone store.

If you’re an aspiring iPhone application developer, there have been some inspiring big-money success stories. For example, Tap Tap Revenge is on an estimated 6.5 million devices. But there’s a huge amount of competition now. A recent estimate is that there are 35,000 applications on the iPhone store (many of which are free).

Is developing iPhone applications a good business model? It’s always fun to play an overly-simplistic numbers game:

Start by assuming that you’re an experienced developer who makes $100 per hour. That’s a lofty rate, to be sure, but I mean someone who’s truly senior and has the credentials and reputation to deliver a sophisticated iPhone application, on budget, with high reliability. If you’re not one of those, you should not be playing this game (and good luck finding one).

Assume you spend the equivalent of one month, or 160 hours, on developing an iPhone application. That’s $16K of development cost. Now suppose you sell the application at the typical 99 cents per download, and that you can average 50 downloads per day. Minus Apple’s cut, you’ve got 69 cents of revenue per unit. To make back the development cost is going to require selling almost 24,000 units, which will take 464 days, or around 15 months.

Too conservative? Maybe in some ways. For one thing, moving 50/day may be typical across the board, but top category apps do 2500/day. Also, in a software start-up endeavor, the average developer cost had better be less than $100/hr (although there’s big time competition for those brains right now). And in that case, you won’t be developing just one application, but rather several of them, in which case you might be able to average less than 160 hours per. The goal is to have a few solid app releases, established a brand, and break into the top per-category lists. If you can get to that point, then, again, you’ll be doing way better download numbers.

On the other hand, the winning strategy right now seems to be to build one or more successful apps as free downloads in order to garner a user base. Then try to monetize later (hey, .com all over again!), perhaps by introducing premium versions. There will be non-trivial marketing and design expenses along the way, probably dwarfing the above development-cost-only numbers.

So – surprise – it’s not the get-rich-quick opportunity that many people seem to think it is. There is significant competition in this space, including from folks who decide to provide similar apps for free, either because it’s just a side project or because they’re doing it as a brand-building strategy.