Cloud Computing: Infrastructure as a Service Webcast

Yesterday saw the webcast of the first in a series of Cloud Computing webcasts - this one on "Infrastructure as a Service". The next ones are looking at "Platform as a Service" (on July 20th) and "Software as a Service" (on September 21st) - don't worry if the dates have passed by the time you come across this blog entry because all of the webcasts are recorded and available via our Past Events page

There was was a good turnout and some good questions asked. Unfortunately we didn't have time to cover all the questions before our hour ran out. We've therefore covered the questions and answers in our Life Sciences blog below:

The first questions we did quickly look at were about Change Control and Configuration Management:

Q. (Change Control) pre-approvals tend to be the sticking points for changes, how have you overcome this
Q. Is there a live configuration management database used?

A. These first questions related to how the Essential Characteristics of Cloud Computing i.e. Flexible On-Demand Service and Rapid Elasticity can be met in a regulated and qualified environment.

Business & Decision does use pre-approved change controls for some types of like-for-like change and we discussed our change control processes in more detail in our webcast "Maintaining the Qualified State: A Day in the Life of a Data Center" webcast on January 12th 2011.

In the same webcast we also discussed the use of configuration management records. Depending on the platform and component our configuration management records are either paper based or electronic and in many cases we use a secure spreadsheet for recording platform or component specific configuration item details. Updates to such electronic records are 'approved' by the sign-off of the controlling change control record and this means that a separate paper document doesn't need updating, printing and signing. This supports the 'rapid elasticity' required in a Cloud model.

Q. If PaaS is provided by 3rd party, would vendor audit be sufficient?


A. Although the next webcast in the series will discuss Platform as a Service (PaaS) in more detail, we did have time to briefly answer this question on-line. Generally an audit of any Cloud provider (IaaS, PaaS or SaaS) would be the minimum that would be required. This is essential to ensure that you understand:
- What service is being provisioned
- Who provisions which parts of the service (you or the third party)
- Who manages the services on a day-to-day basis
- Where they provision the service (where your data and applications will reside)
- How you, as the Regulated Company, can provide effective control (and demonstrate accountability to your regulators)
- How they provision and manage the relevant services (and do they actually do what their Policies and Procedures say that they do)
- What are the specific risk scenarios, the risk likelihood and what risk controls need to be established beyond the providers standard services

Whether any addition actions would be required would depend on the outcome of the initial audit. In some cases infrequent surveillance audits are all that would be required. In other cases additional metrics may need to be established in the SLA and in some cases it might be determined that some services will need to stay On-Premise. If people download the slides from our website (let us know if you need to know how) you'll be able to see the flow chart for this process.

Q. In case of IaaS, provisioning is tightly coupled with PaaS and thus required to provisioning of PaaS as well. How can your on-demand provisioning can be achieved in a minute? 

A. Our experience is also that in the real world, at least contractually, the provisioning of Infrastructure as a Service is coupled to Platform as a Service i.e. we provide the complete Platform, including the infrastructure components (this also fits much more realistically with the GAMP definition of Infrastructure, as discussed yesterday). However in many cases the change is at the level of "processing, storage, networks, and other fundamental computing resources" (to use the NIST definition of IaaS), so it really is IaaS within a broader PaaS model.

It is certain infrastructure components that can be technically provisioned in a minute or so - additional storage, network connections etc - this is usually just a change to a configuration parameter. You obviously need to add on the time to raise the change control and update the configuration management record, but for small changes that don't need client approval (because this is based upon a client request), and because these processes and systems use electronic records it can still be done in minutes rather than hours.

For physical infrastructure items (e.g. additional memory or CPUs) we can make the physical change and reboot the server also in a matter if minutes. Where we need to prepare a new environment (e.g. switch the clients application to a different virtual machine with the right infrastructure) this may need additional time to prepare, but the downtime for the client can also be a matter of moments as we reallocate IP addresses etc.

Even where we have had to provision new virtual machines (which really is PaaS) this is done in a matter or hours as we not only leverage standard specifications/designs and build, but we also leverage standard qualification documentation to ensure that the qualification process doesn't slow things down.

While it's true that most PaaS changes require more than a few minutes, it's usually a matter of hours rather than days.

Q. How are security exposures addressed within a IaaS scenario? (If the IaaS is not responsible for OS?) 

de-provisioned) such as storage or memory or CPUs then there should be no fundamental change in the risk scenario previously assessed. e.g. when you allocate additional disc capacity at a physical level it 'inherits' the security settings and permissions to which it is allocated. Issues with the database security are handled at the level of PaaS and any allocation of new database tables would of course need a reassessment of risk. The same is of course true regarding memory and CPUs.

At the IaaS level it is network capacity and specifically routings that need more thought. Allocating bandwidth to a specific client or application within a T1 pipe is again a matter of configuration and doesn't affect the associated security settings. Making changes to routings is of course more 'risky' and would require us to look again at the original risk assessments.

Most security risks do occur in the PaaS and SaaS models which we'll be looking at in more detail in the future webcasts in this series.


Thanks again for everyone for joining us on the webcast yesterday - if you missed it the recording will stay on line as long as the infrastructure is provisioned by BrightTalk! We hope you'll join us agian soon.