23
Feb

Apps for SharePoint 2013 carry their own set of implementation risks

2-Color-Design-Hi-Res-100px-widthLarge organizations with an instance of Microsoft SharePoint running on premises may be thinking about migrating their customization process over from full trust solutions to a combination of HTML, CSS and JavaScript. Microsoft refers to this combination as the “SharePoint App Model”. A similar combination called the “Office App Model” is also being promoted for requirements to modify the components of Microsoft’s Office suite (“Office”) to meet the unique requirements of specific organizations.

Despite what I refer to as a near “binary” presentation, where the strengths of these app models (the “pluses”) are presented in direct comparison with the weaknesses of their full trust solution ancestors (the “zeroes”), readers with similar interests will benefit if they include a governance plan for customization along with the other migration components. Here is why:

jQuery is a popular function library for JavaScript. Since jQuery is actively supported in the user community, the library continues to evolve. Hence there are many different versions of the library. But not all features of all libraries are the same. So conflicts can arise from customizations built with earlier versions of the jQuery library. Especially when these customizations are actively used alongside other customizations built with other versions of the library.

The negative impact of these conflicts is greater when a central IT organization steps back and opts to empower line of business (LoB) units to build their own customizations for an on-premises complex computing platform like SharePoint 2013. On the surface this approach may look to be the correct one to take, especially if this stance has evolved after several years of an active BYOD policy.

Some proponents of Dev/Ops may recommend this kind of flexible posture on the part of enterprise IT. But if there is no central control over how jQuery libraries are to be implemented, then the risks of a breakdown in computer processing take on a more palpable shape. A far better policy calls for enterprise IT to directly arbitrate with LoBs on the question of how customizations are to be managed. In fact, enterprise IT ought to publish a set of standards for how customizations are to be built with SharePoint and/or Office apps. Finally, a set of tools should be implemented (and developed if they are not found to be available given the unique needs of a specific organization) capable of detecting processes running on internal on-premises computing systems to ensure any/all examples of app customizations are in conformance with this policy.

Without this kind of governance plan, larger organizations will face much the same odds of poor return on development investment from app model efforts, as would be the case if they simply proceeded with “legacy” customization techniques.

Ira Michael Blonder

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

16
Oct

Pluses and minuses of the app model on cloud, SaaS computing

Early versions of SaaS served from the Internet cloud looked a lot like time sharing applications. In other words, each and every web visitor looked like just another terminal on a remote server. The use of small form factor computing devices had not yet occurred, and the browser options for clients to consume services were all working in pretty much the same manner.

But with the advent of the app model, the client side of these solutions is a lot more complex, and, potentially, more difficult for organizations to manage. There are a few very important positives motivating cloud, SaaS ISVs to promote, and even require the use of apps:

  • Apps are a promising method of attracting the interest of developers. App stores exist for every prominent cloud SaaS offer. Developers sell their apps, and ISVs can charge a premium for clearing transactions through their app stores
  • As long as secure development procedures are followed, there is no limit on the range of new functionality developers can add to SaaS platforms. ISVs benefit from zero capital expense for the creation of new functionality. End customers benefit from a wider range of possible applications
  • By transitioning processes from the server to the community of clients consuming a SaaS solution, it can be argued processes are more secure. Server maintenance costs are also likely to be substantially reduced

But there are minuses anyone studying cloud, SaaS product marketing must, in this writer’s opinion, keep in mind. Fortunately (or unfortunately depending on how one looks at it) most of these minuses are specific to apps:

  • Transitioning potentially harmful processes off the server and over to client side apps shifts the security burden over to individual consumers, and groups of consumers. Since it is not likely to be possible to estimate just who will opt to consume SaaS and, therefore, purchase and implement apps, the task of ensuring a uniform quality of service (and basic data communications security) is very difficult to manage. Neither ISVs, nor enterprise organizations can claim complete responsibility for this job.
  • Opportunities for malicious activity geometrically increase as the number of SaaS consumers grows. There is no way ISVs can ensure the security of computing devices enabled with apps. So the potential for hacks should be assumed to be high. As of the time of the writing of this post, Dropbox, the latest SaaS to notify the public of a security breach, actually blamed app developers for the security hole used for the exploit
  • Enterprise businesses with a formal BYOD policies may see a dramatic increase in the need to support users. When apps are running on a set of dissimilar computing devices (Android, and/or Apple smart phones, tablets, etc) the need for expertise on multiple platforms arises. It can be costly for enterprise IT to provision the support required to ensure SaaS consumers can get the services they need

Given the factors just presented, we think it likely Enterprise Mobility Management (EMM) solutions like Windows Intune will become very popular across enterprise business customers.

Ira Michael Blonder

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

30
Sep

No Technology Solutions on the Near Term Horizon for a Better Defense Against Online Hacking

ISVs with popular online computing offers (notably Apple, Google, and Microsoft) have each adopted and endorsed an “App” model. This writer has a lot of conceptual familiarity with Microsoft’s version of this approach. Microsoft has positioned its Office 2013 App Model as a better approach to online security, but is it really?

For readers unfamiliar with the broad technical structure of “Apps” and how it might enhance online security for consumers, the key principle is “isolation”. In theory, “Apps” transition a lot of computer processing from servers to clients. In other words, a lot of the activity handled in the past by the server is transitioned over to the PCs, smart phones, tablets, and even game consoles consumers use to process computing tasks online. The method of processing this activity is to instruct these computing clients to act on commands written in some version of the JavaScript programming language, or the latest version of HTML (HTML 5 at the time of this post).

In the case of the Office 2013 App Model, the jQuery (http://www NULL.jquery NULL.org) function library is heavily used by developers to add procedures quickly, which already exist somewhere online, with all of the supporting libraries required for successful execution. But this practice poses several difficulties, a couple of which directly impact on online security for consumers. First, there are different versions of the jQuery function library. So, when an App is developed with one version, and another App is added to a computing environment (for example, Office 365), the potential for App conflict arises, which can result in degradation of service for the end consumer.

Second, inadvertently to advocates of this type of development, the App model’s reliance on a client-side method like JavaScript can be said to insulate the server, but, inadvertently, this approach shifts the burden of security over to the client. Since their are hundreds, if not thousands, and even millions of different clients in use to interact with one server (or many servers in a load-balancing scenario, which act as one server), there is a much higher likelihood of a security breach on a client machine. Once clients are successfully compromised, they can be added to bot networks and re-purposed for other types of malicious activity.

For better or worse, in late 2014 the best defense against malicious online activity remains best represented by a correct set of operational risk management processes, at least for large organizations of users.

Ira Michael Blonder

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