Cloud computing has the potential to drive significant value to organizations through increased IT efficiency, agility and innovation; but a clear understanding of exactly what is to be moved and how the cloud
So, how should enterprises go about conducting this analysis? The first step is to identify the individual IT assets that will be subject to the analysis. Each asset may be a database, a website, an application, a business process or some combination thereof. Note that this step does not need to encompass every single IT asset within the organization, only those that may be candidates for migration to a cloud computing environment.
For each of the assets that we’ve identified we now need to get a detailed understanding of how they are used by the organization. We should be looking to identify information such as:
- What is the security classification and sensitivity of the information associated with the asset? Are there social security numbers, credit cards and health information that require special consideration? Who are the users and where are they located?
- Who are the end users and where are they located? Are they internal or external to the organization? What level of local infrastructure is available for network access and what types of mobile devices need to be supported for access?
- Who are the administrative users that will require privileged access and what are the requirements for least privilege and separation of duties that must be supported?
- What are the underlying storage, processing power and bandwidth required to deliver the asset to the users? Are there predictable spikes in capacity requirements, such as quarterly reporting or following the announcement of a new product offering?
- What underlying operating systems, database engines and other components are required? How do these platforms map to the organization’s enterprise architecture and other applicable technology standards?
- How does information asset integrate with other systems, processes or other organizations? Are there ancillary systems that are critical to the delivery of the asset? Should the scope of the information asset under consideration be broadened to include these other systems?
Once an inventory of the asset and its attributes is completed, it’s time to conduct an asset valuation. This may be the cost associated with creating the asset or the level of mission criticality of the asset. This valuation should also include a determination of the negative impacts to the organization if the asset were to be compromised in various ways, such as the asset becoming widely public and widely distributed, manipulation by an outsider, unauthorized changes to data and unavailability of the asset or poor response time in support of mission critical operations.
Creating logical groupings of the assets analyzed is the next step. For example, are there platform or security requirements that are common to many of the assets? Are there assets that have similar valuations or negative impacts due to compromise? Are there assets that apply to a certain mission or business areas, such as R&D or financial management?
The next step is mapping the attributes and requirements associated with each of the logical groupings to viable cloud models and the capabilities of various providers and their specific service offerings. This step is likely to be highly iterative, as various candidate models and providers will be considered for each grouping before a recommendation on an implementation approach is made. By grouping information assets into asset classes, we can achieve greater economies of scale through whichever cloud model is selected. We can also expect that different deployment models and service providers will be considered appropriate for different asset classes.
More resources on risk tolerance and cloud computing
When mapping attributes and requirements to deployment models and specific vendor capabilities, we want to come away with three things:
- Target Architecture: This should be a depiction of the system and network architecture. Of particular importance is the location of data, connectivity with the CSP and identity management and associated security controls.
- Concept of Operations: This should delineate responsibilities between the customer and service provider for Tier 1/2/3 help desk, response times, security incident response processes, ongoing vulnerability assessments, support for VIP users and handling of peak processing loads.
- Implementation and Migration Plan: This should identify the high-level milestones and costs required to implement and migrate the information asset to the cloud model. This should consider data migration, end-user training and organizational change management.
With these three outputs in hand, we can consider our risk tolerance in these areas:
- Security: Are the technical and operational security controls appropriate for the sensitivity of the information and the valuation of the asset? Will security operations support regulatory requirements for incident response time or compliance with privacy laws? Will information be kept secure while it is being migrated to the cloud environment?
- Operations: Will VIP users receive appropriate levels of support in the cloud-based implementation? Will peak performance requirements be met? Will response time to incident reports meet expectations? What service-level agreements (SLAs) should be put in place to ensure that operational expectations are met?
- Organizational: Does the cost/benefit model support the given cloud implementation approach? Can the implementation be completed in an acceptable timetable with minimal impacts to users? Last but not least, has buy-in been received from appropriate levels of management regarding the changes that are associated with the cloud model?
Organizations will optimize the benefits they receive from cloud computing by applying a structured, analytical approach to determine which IT assets and services should be moved to the cloud, the risks associated with moving those assets and the organizations risk tolerance.
This was first published in June 2012