May 11, 2012 | Written by: Turgut Aslan
Share this post:
Cloud computing is about automation, standardization, and optimized resource management and usage, and therefore, more agile and cost-effective service delivery for internal and commercial customers. IBM’s commercial customers often have special security needs and considerations as documented and signed in the customer security policies and technical specifications documents. Those agreed settings might sometimes contradict the streamlined settings in a cloud solution. The question here is, how can contracted security needs of commercial customers be ensured and automated during delivery of the contract in a cloud offering? Obviously a robust risk and issue management is needed to take the benefits of cloud offerings while not compromising contracted security policies. This blog entry is about managing risks and issues when providing cloud services to commercial customers. Managing service provider internal risks when using cloud technology is out of scope of this blog entry. Also any risk evaluation whether or not to migrate information assets or applications to cloud solutions is not regarded here.
Risks and issues management challenge
Commercial customers have their internal security policies. When they outsource all or part of their IT infrastructure, a security controls document should be signed together with technical specifications appendixes. Those documents will define the security settings to be implemented and regularly reviewed for various platforms, operating systems, middleware, and applications. They should also define special considerations, limitations, or settings applicable to that customer.
Many companies will have their risk and issue management processes. A good practice is to document known risks and issues when the contract and the related security controls document are signed. Those risks and issues should be mitigated and addressed, or appropriate customer risk acceptances should exist. This documentation will help in case of any audits.
When it comes to the implementation of the customer-agreed settings and the operation in a business-as-usual mode, already known or new risks and issues will arise. In many cases, both service provider and service recipient will be involved in a very time consuming manual effort to detect, assess, document, notify, discuss, mitigate, and report risks and issues, where often a case-by-case handling can be done only. This approach will often contradict the automation and standardization approach in a cloud.
How can risks and issues be automatically addressed in a cloud offering?
Two examples of customer communication, which can be implemented easily and are already frequently used today, are:
- Automated, system-generated commercial customer notifications in case of deviations to previously agreed security settings
- Notifications in case of matching security patch information to applicable customer servers
An automated assessment of the security settings deviations, according to a predefined table, can be done. In case of a security patch, the severity according to, for example, a vendor-provided initial assessment can help to assess the related risk also. Together with the customer notification, those initial risk assessments can be documented in an automated fashion.
The missing link here often is between the automated customer notification and the potentially available risk acceptances of the commercial customer. So, for example, predefined change windows might exist where servers can be patched and rebooted with the necessary risk documentation and acceptance by the commercial customer. The process would still require customer notification, an agreement on the change window, or appropriate risk communication. But, because all of that is available, no security compliance issue would emerge.
The handicap in many solutions used today is that various databases do not talk to each other: It starts often with the manually created and signed contract, security control documents, and technical appendixes stored in various databases with all kinds of formats. Then, we have more or less standalone databases for server and software inventory, which might be relevant to a process we want to automate in a cloud offering. And finally, there might be a separate database for risk and issue documentation, and some existing standard disclaimer texts too.
Combining those elements into an end-to-end solution will enable an effective, that is, automated risk and issue management. The process, for example security patch management, would allow this automation while still granting compliance and therefore successfully passing audits. The automated commercial customer notification would already have all the references and links to the agreed security setting documents, agreed change windows, available customer risk acceptances, and standard disclaimers. To establish this cloud offering with automated risk and issue management interfaces between the various contract, security controls and technical specifications, risk and issue databases with machine readable information, and an interface to help desks data must be established.