Cloud Migration of a Legacy IT Estate

There are many things to consider when migrating a legacy IT estate to the cloud. The first though must be what are the motivations and expected benefits. Many organisations have many decades of developed software running on private infrastructure and migration to the cloud is something they think they should do.

Migrating an estate to the cloud incurs a significant cost hurdle as new functions are required just to support migration activities. Often the benefit is minimal as only limited efficiencies can be found from closing (or worse partial closing) of legacy applications and data centres.

What is needed is a target systems architecture aligned to business benefits and vertical product supporting IT Stacks.

The systems architecture should reflect management of intermediary states between internal hosting and public cloud. The management of intermediary estates can easily increase an organizations run cost; for example if Corporation A decides to migrate all of its channels’ IT to a public cloud it will need to build an integration from public to private infrastructure, lease connection between new and old sites, provide a security wrap and identity mgmt function across internal and external clouds and finally support the operations for managing these new systems.

The benefits to support all of these new cloud enablement functions will be high. This does not mean it should never be done but the business must address how benefits like improved time to market will be substantively realised.

A TOGAF business architecture should be included before migrating as migration for the sake of hosting will only ever be a platform change. The balance has to be on how much change your organisation can stomach in a single move. Always consider that the SaaS services you are considering will probably be more configurable than your legacy estate. So don’t fall into the myth of business architecture as business change does not always have to be front loaded.

Securing Smart Device Communication using ETSI M2M Service Capability Layer (SCL)

Smart M2M devices require authentication & registration with the mobile network. Standardisation of service is proposed by the ETSI Service Capability Layer deployed to the Mobile Internet Device / Gateway. Security between the network and the mobile internet device requires authentication, key agreement and establishment that enable M2M Service Bootstrap, provisioning and M2M Service Connection procedures that are grounded on a clearly defined key hierarchy of the M2M Node.

The European Telecommunications Standards Institute’s M2M Release 1 provides standardised security mechanism for the reference point mobile internet device. This architecture is based upon the following principles:

  • ETSI M2M adopted a RESTful architecture style with information represented by resources structured as a tree
  • ETSI M2M standardises resource structure that resides on an M2M Service Capability Layer (SCL) where each SCL contains a resource structure where the information is kept
  • M2M Application and/or M2M Service Capability Layer exchange information by means of these resources over the defined reference points
  • ETSI M2M standardises the procedure for handling the resources

ETSI M2M Diagram

The SCL is deployed to the M2M mobile Internet device (mId) / gateway and requires authentication & registration with the M2M network. ETSI M2M provides standardised security mechanisms for the reference point mId. Mobile Internet Devices/gateways hold secret keys protecting the connection in a “secured environment” and are provisioned with the key M2M Root Key (Kmr)

This requires using RESTful operations over the mobile internet device:

  1. M2M Service Bootstrap:  provision M2M service provider assigned ID & M2M Root Key (Kmr)
  2. M2M Service Connection: mutual AuthN of mobile internet device end points & generation of M2M Connection Key (Kmc – derived from Kmr)
  3. (Optional) Mobile Internet Device security: establishment of secure communication over mobile internet device based on Kmc (and sub-keys)

More information:

ETSI M2M Security Standards 

Moving Away from a Push Model for Enterprise Identity Architecture

The discipline of Enterprise Architecture and an architecture for identity management do not currently have a best practice. The TOGAF discipline of Enterprise Architecture promotes a holistic and systemic view for interoperable systems; these may be supply chains, business processes or identity repositories. The Emerging Architecture of Identity Management argues that identity management is based on a push model with provisioning from an authoritative source as its locus. This push model exists because as enterprise systems proliferated the only viable HR approach was to provision identity to each subsequent enterprise system.

The Open Group white paper on Identity Management (W041) presents an architecture based on Delegated Authority and a master Authoritative Source. This model is firstly a push model with trust provisioned down to enterprise systems.

It is time for a review of this architecture because from an Enterprise Architecture discipline a systemic best-practice must be aware of growing trends and technology driven best practice. This author believes that authorisation needs to be contextualised and separated from joiners and leavers processing. Authorisation requires more intelligence and the proliferation of OAuth and Facebook APIs into enterprise systems (e.g. Social Authentication) will require enterprise’s to have a better approach to Attribute Based Access Control. This will provide the further benefit of not requiring enterprise’s to invest on enterprise system provisioning connectors which require regular updating and often manual intervention for everyday tasks such as promotions, demotions, joiners & leavers.