Our next section will be section 21, entitled information security, infrastructure, and architecture. We know that a building of any kind cannot be structured without an architect developing a design putting together a blueprint of what the end product should look like and how it is structured. The components of this architectural design be it a system, or a building, or a ship describes the infrastructure components that will make it up and see to its functioning.

It begins with the foundation, and the foundation that we have described begins with the philosophy of defense and depth and couples that with the intended function of the completed structure. This infrastructure will include all the computing platforms the networks that bind them together, any middleware and will place on top of this the applications that the intended endpoint consumers will operate to perform the functions that the system is designed to perform.

In looking at our enterprise information security architecture, we're going to look at how to design the information systems, networks, and applications to align with the corporate goals and requirements. As such, it is going to be designed to prevent ad hoc network infrastructure and ensure that all components fit to the particular design to ensure this alignment.

A business itself may grow organically as we say, in other words directly in response to changing conditions, but the information infrastructure cannot afford to do that simply because it may grow in directions that may take it off the path of alignment with the corporate direction. So we establish goals that include the provision of structure, serve as a roadmap in the form of a general design to be followed and mapped to the corporate evolution.

Strategic alignment with this evolution and supportive business strategy, provide traceability back to the business requirements and objectives, be described functionally rather than in detailed technologies and infuse a common lexicon for the discussion of security in the context of the system and the business environment.

To do this, we have to look at different segments of this architectural design. This will include the development or adoption process models, the infusion and integration of various frameworks and various types of reference models to illustrate the concepts and requirements that we need to embed in this architecture and whose requirements we need to meet for compliance purposes.

Another business architecture will define high level strategies that the information systems infrastructure will need to describe and implement. In the layers you see on the slide, these might each be integrated with the others and the whole integrated with the business architecture itself.

Our layers, our business architecture, data architecture, applications architecture, and technology architecture. Initially these are defined in a functional manner, but before implementation and integration with the operations of the actual organization, they need to be described in sufficient detail to enable proper and full integration for implementation.

As one example of an enterprise information architecture we see here, the layout of the Sherwood Applied Business Security Architecture or SABSA a similar type of an architecture is the Zachman architecture. As you can see by the illustration on the slide the matrix of Sherwood is arranged in six different contexts from the top down contextual, conceptual, logical, physical, component and service management.

Across the top, we have the columns that define assets, motivation, process, people, location and time. At each intersection, the box shown talks about what needs to be decided and what needs to be accomplished at a functional level. This architecture aligns very closely with the ISO 27,000 series and the ITIL Service Oriented Architecture model as well. The purpose of this is to ensure that in observance of business as the driver in the center of these priorities, the architecture for information systems must align closely with it.

Now we move on and discuss Cloud computing. In the conclusion of our discussion concerning architecture, it is imperative that we understand the business, its priorities, its goals, its objectives, its organization and its culture in order to properly define and integrate an information management architecture to ensure success of both.

As we said before, security must be in place and information systems must operate properly but all must be in balance with your organization and the technologies to enable success for the whole. One of the main goals of the certified information security manager's role would be to ensure that these priorities and necessities are recognized and that the balance is achieved. And now we move on to section 22 to continue our discussion of these vital points.

So we begin our discussion of Cloud computing by looking at the definition from NIST that defines what it is. To quote NIST, "Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction."

This definition comes from Special Publication Series 800 volume 145. It is very simple to say that the Cloud is a euphemism for the internet. The term comes from telephone companies whose linemen would install the various connections that they needed to and would call the overall telephone network, the Cloud due to its constantly changing and expanding shape.

Now in that same document that defined what Cloud computing was, NIST also gave additional characteristics that define Cloud as a distinctly different from computing models of a more traditional kind. It defined key drivers that would bring an organization to consider and possibly convert from on-premises to Cloud computing.

A main driver initially and still partially today, is the shift from capital expenditures to operational expenditures. In addition to that, Cloud provided potential advantages of increased scalability, elasticity, virtualization, mobility, facilitation, collaboration, and risk reduction.

Part of the motivation for an organization to move to Cloud computing was to shorten the time that existed between a recognized need and the addition of the capability and capacity to meet that need. In addition to that, there was a need to give greater control over those who were at the point of usage, to align capacities with needs in a more prompt and contextually appropriate fashion.

There was also of course, the traditional motivator of trying to save money and Cloud computing appeared to be a way to do that. The Cloud, however, brought with it a new way of looking at and having to consider various forms of risk and security to deal with the ad risk now that the Cloud may or may not be as secure or securable as your on-premises systems might be.

Today there are traits that come with Cloud computing that your on-premise systems also may not have. In the graphic, you see that we have Cloud computing at the center and around it we have various representative concerns. The multi-tenant security environment means that it's not just us out there in the Cloud but that we have neighbors.

We have privacy concerns whenever we store personally identifiable or other types of sensitive information, we have of course our business risk and reputational risk associated with being in the Cloud and in the event that adverse events should take place, legal and regulatory issues are still here and the Cloud is simply a new environment in which they will exist. And unlike our on-premise systems, Cloud computing will bring with it, these issues in a form that we may not have had to contend with before.

Now, bearing those previous points in mind, let's look at where responsibilities lie and where the boundaries lay for responsibilities and for accountabilities. The graphic that you see on this slide was developed by the Cloud Security Alliance to illustrate where the boundaries lie and who was responsible at each point for which component.

We have across the top, the three basic service delivery options, infrastructure as a service, platform as a service, and software as a service. Down the left-hand margin, we see various characteristics, at the top governance, data security, application security, platform security, infrastructure security, and at the bottom, finally physical security.

The grid itself showing the various intersections between the left-hand column and the top layer shows the intersections running from the Cloud provider's responsibility at the lowest levels to enterprise responsibility at the upper levels and then a layered of shared responsibilities in between.

As can be seen, moving from infrastructure as a service, the enterprise becomes more responsible because more of the stack, so to speak, is in the operator's hands of the enterprise itself. Whereas at the far right under software as a service, the enterprise becomes almost an end-user only. And with each change moving from left to right, the responsibility shift more and more to the Cloud provider and away from the Cloud user.

To the extent that this grid holds true in any given environment, it means that solutions for security and privacy as well for all the operational issues normally associated with this, have to be determined in how this unique environment notice the Cloud.