Tag Archives: best practice

The Cloud, multiple Platforms within Platforms

By Mark Skilton, Capgemini

I recently attended The Open Group India Conference in March. This was the first time that The Open Group India had launched such an event, and they had the ambitious target of visiting three cities in the week. The event itself was a platform for discussion of Indian perspectives on all aspects of Architect Best Practices, and in particular, the India market on Enterprise Architecture and Cloud Computing. It drew a significant cross section of public and private industry sector professionals at all the venues, with keen debate and presentations demonstrating industry-leading thought leadership and case study.

The highly successful event raised important questions and discussion on significant topics of the moment in architecture and the Indian perspective. One that stands out in Cloud Computing was the development of Cloud Architectures and the role of Cloud as a platform for services.

Significant Cloud Computing commentary from the Cloud panel sessions included:

  • The role Indian government IT services strategy development could play in applying Cloud Computing, Grid and SOA concepts to the public sector services to the federated and regional citizenship
  • How the Indian market could exploit the SMB and youth demographic that see the Cloud as a rapid resource delivery platform, and huge potential for services in the Cloud to local and international markets
  • The evolution of Cloud services, notably in Big Data and content as a service and in applications software development in the Cloud using PaaS. Both need further focus on master data semantics and interoperability standards to help versioning, persistence of data and support of multiple Cloud virtual environments to drive the potential reality going forward

The debate of Cloud Architectures and Platforms ran throughout the three-city Conference, with notable observations and lessons learnt, including:

  • Support of multiple locations by “location-aware Clouds” was an interesting aspect when developing shared platforms that need to recognize the delivery and localization of “last mile logistics” and end-user experience of the service. One-size-fits-all needed some abstraction of end point use in enabling adoption flexibility and relevancy
  • Cloud Architectures had to be “platforms” that “evolved” like the ecosystem that made up its internal and external components and services. This was a fact as many Clouds and integration adaptor strategies using open source and proprietary technologies where driving ahead with different standards and speeds of development. Understanding the solution options needed to “design for change” was a matter of urgency in architectural design practice for Cloud
  • Mobile Cloud, including the Internet of things (IoT) and the spread of mobile channel services everywhere, drew considerable interest as a strong potential second wave of the Cloud as it enters the next stage of added-value services, virtual communities and multi-Cloud service marketplaces

The underlying theme seemed to be the emergence of service platforms and services enabled by the Cloud and its pervasiveness into social media and social networks underpinned by Cloud infrastructure and data centers. Platforms enabling other platforms in a distributed regional, wireless, global bandwidth enabled world.

I remembered that, at the same time as the Indian event, there was a shining example of technological inspiration right above our heads orbiting 200 miles around the Earth: the STS133 mission and final space flight of the Space Shuttle Discovery. This in itself was an inspiring magnificent achievement. The shuttle had flown more missions than any other — 39 in the 25-year flight history — but that was not the whole picture. Discovery was the platform that launched another platform, the Hubble Space Telescope, into the heavens. And look what discoveries came of that: the first pictures of the now-famous Eagle Nebula stellar nurseries, new insights into the distribution of galaxies and the universal constant, and the list goes on. One platform borne upon another; how much further will our children see tomorrow?

Cloud Computing will be a topic of discussion at The Open Group Conference, London, May 9-13. Join us for best practices, case studies and the future of information security, presented by preeminent thought leaders in the industry.

Mark Skilton, Director, Capgemini, is the Co-Chair of The Open Group Cloud Computing Work Group. He has been involved in advising clients and developing of strategic portfolio services in Cloud Computing and business transformation. His recent contributions include the publication of Return on Investment models on Cloud Computing widely syndicated that achieved 50,000 hits on CIO.com and in the British Computer Society 2010 Annual Review. His current activities include development of a new Cloud Computing Model standards and best practices on the subject of Cloud Computing impact on Outsourcing and Off-shoring models and contributed to the second edition of the Handbook of Global Outsourcing and Off-shoring published through his involvement with Warwick Business School UK Specialist Masters Degree Program in Information Systems Management.

1 Comment

Filed under Cloud/SOA

The Trusted Technology Forum: Best practices for securing the global technology supply chain

By Mary Ann Davidson, Oracle

Hello, I am Mary Ann Davidson. I am the Chief Security Officer for Oracle and I want to talk about The Open Group Trusted Technology Provider Frameworkhardware (O-TTPF). What, you may ask, is that? The Trusted Technology Forum (OTTF) is an effort within The Open Group to develop a body of practices related to software and hardware manufacturing — the O-TTPF — that will address procurers’ supply chain risk management concerns.

That’s a mouthful, isn’t it? Putting it in layman’s terms, if you are an entity purchasing hardware and software for mission-critical systems, you want to know that your supplier has reasonable practices as to how they build and maintain their products that addresses specific (and I would argue narrow, more on which below) supply chain risks. The supplier ought to be doing “reasonable and prudent” practices to mitigate those risks and to be able to tell their buyers, “here is what I did.” Better industry practices related to supply chain risks with more transparency to buyers are both, in general, good things.

Real-world solutions

One of the things I particularly appreciate is that the O-TTPF is being developed by, among others, actual builders of software and hardware. So many of the “supply chain risk frameworks” I’ve seen to date appear to have been developed by people who have no actual software development and/or hardware manufacturing expertise. I think we all know that even well-intended and smart people without direct subject matter experience who want to “solve a problem” will often not solve the right problem, or will mandate remedies that may be ineffective, expensive and lack the always-needed dose of “real world pragmatism.”  In my opinion, an ounce of “pragmatic and implementable” beats a pound of “in a perfect world with perfect information and unlimited resources” any day of the week.

I know this from my own program management office in software assurance. When my team develops good ideas to improve software, we always vet them by our security leads in development, to try to achieve consensus and buy-in in some key areas:

  • Are our ideas good?
  • Can they be implemented?  Specifically, is our proposal the best way to solve the stated problem?
  • Given the differences in development organizations and differences in technology, is there a body of good practices that development can draw from rather than require a single practice for everyone?

That last point is a key one. There is almost never a single “best practice” that everybody on the planet should adhere in almost any area of life. The reality is that there are often a number of ways to get to a positive outcome, and the nature of business – particularly, the competitiveness and innovation that enables business – depends on flexibility.  The OTTF is outcomes-focused and “body of practice” oriented, because there is no single best way to build hardware and software and there is no single, monolithic supply chain risk management practice that will work for everybody or is appropriate for everybody.

BakingIt’s perhaps a stretch, but consider baking a pie. There is – last time I checked – no International Organization for Standardization (ISO) standard for how to bake a cherry pie (and God forbid there ever is one). Some people cream butter and sugar together before adding flour. Other people dump everything in a food processor. (I buy pre-made piecrusts and skip this step.) Some people add a little liqueur to the cherries for a kick, other people just open a can of cherries and dump it in the piecrust. There are no standards organization smack downs over two-crust vs. one-crust pies, and whether to use a crumble on the top or a pastry crust to constitute a “standards-compliant cherry pie.” Pie consumers want to know that the baker used reasonable ingredients – piecrust and cherries – that none of the ingredients were bad and that the baker didn’t allow any errant flies to wander into the dough or the filling. But the buyer should not be specifying exactly how the baker makes the pie or exactly how they keep flies out of the pie (or they can bake it themselves). The only thing that prescribing a single “best” way to bake a cherry pie will lead to is a chronic shortage of really good cherry pies and a glut of tasteless and mediocre ones.

Building on standards

Another positive aspect of the O-TTPF is that it is intended to build upon and incorporate existing standards – such as the international Common Criteria – rather than replace them. Incorporating and referring to existing standards is important because supply chain risk is not the same thing as software assurance — though they are related. For example, many companies evaluate ­one or more products, but not all products they produce. Therefore, even to the extent their CC evaluations incorporate a validation of the “security of the software development environment,” it is related to a product, and not necessarily to the overall corporate development environment. More importantly, one of the best things about the Common Criteria is that it is an existing ISO standard (ISO/IEC 15408:2005) and, thanks to the Common Criteria recognition arrangement (CCRA), a vendor can do a single evaluation accepted in many countries. Having to reevaluate the same product in multiple locations – or having to do a “supply chain certification” that covers the same sorts of areas that the CC covers – would be wasteful and expensive. The O-TTPF builds on but does not replace existing standards.

Another positive: The focus I see on “solving the right problems.” Too many supply chain risk discussions fail to define “supply chain risk” and in particular define every possible concern with a product as a supply chain risk. (If I buy a car that turns out to be a lemon, is it a supply chain risk problem? Or just a “lemon?”) For example, consider a system integrator who took a bunch of components and glued them together without delivering the resultant system in a locked down configuration. The weak configuration is not, per se, a supply chain risk; though arguably it is poor security practice and I’d also say it’s a weak software assurance practice. With regard to OTTF, we defined “supply chain attack” as (paraphrased) an attempt to deliberately subvert the manufacturing process rather than exploiting defects that happened to be in the product. Every product has defects, some are security defects, and some of those are caused by coding errors. That’s a lot different – and profoundly different — from someone putting a back door in code. The former is a software assurance problem and the second is a supply chain attack.

Why does this matter? Because supply chain risk – real supply chain risk, not every single concern either a vendor or a customer could have aboutManufacturing a product – needs focus to be able to address the concern. As has been said about priorities, if everything is priority number one, then nothing is.  In particular, if everything is “a supply chain risk,” then we can’t focus our efforts, and hone in on a reasonable, achievable, practical and implementable set  – “set” meaning “multiple avenues that lead to positive outcomes” – of practices that can lead to better supply chain practices for all, and a higher degree of confidence among purchasers.

Consider the nature of the challenges that OTTF is trying to address, and the nature of the challenges our industry faces, I am pleased that Oracle is participating in the OTTF. I look forward to working with peers – and consumers of technology – to help improve everyone’s supply chain risk management practices and the confidence of consumers of our technologies.

Mary Ann DavidsonMary Ann Davidson is the Chief Security Officer at Oracle Corporation, responsible for Oracle product security, as well as security evaluations, assessments and incident handling. She had been named one of Information Security’s top five “Women of Vision,” is a Fed100 award recipient from Federal Computer Week and was recently named to the Information Systems Security Association Hall of Fame. She has testified on the issue of cybersecurity multiple times to the US Congress. Ms. Davidson has a B.S.M.E. from the University of Virginia and a M.B.A. from the Wharton School of the University of Pennsylvania. She has also served as a commissioned officer in the U.S. Navy Civil Engineer Corps. She is active in The Open Group Trusted Technology Forum and writes a blog at Oracle.

6 Comments

Filed under Cybersecurity, Supply chain risk