What does it take to satisfy a regulator?

I've been working recently with a major financial services firm on its adoption of cloud computing infrastructure and services.  We've been thinking at length what it is going to take to persuade and satisfy regulators and the Chief Risk Officer that moving application workload to the cloud is safe.


At the heart of regulatory concerns is whether cloud service providers and financial services firms can manage exposures and vulnerabilities.  As cloud computing encourages the use of shared multi-tenant resources, there is a strong focus on ensuring that financial services data is highly protected and that one client of a shared environment cannot negatively impact another through an accidental or intentionally malicious action.

When thinking about how to create confidence, a simple framework that outlines the core concepts is necessary. I'd like to describe one of the ways we've been thinking about this.

• Control Entities

• Monitoring Approach

• Reporting

• Incident Management

Control Entities:

This relates to which components within a cloud environment may be subject to regulatory oversight.

So far, the list is likely to include (but not limited to) the following:

• Hypervisor

• Physical Server

• Virtual Server

• Container

• Storage System

• Styles

• File

• Object

• Block

• Dedicated Storage Server

• Shared Storage Server

• Physical HDD (or equivalent) that is locally attached to a server or storage server

• Software Defined Storage Overlay

• Archive System

• Backup System

• Physical media

• Network

• Physical Networks

• Virtual Networks (VLAN

• Software defined overlay, eg. VMware NSX

• VPNs

• Dedicated connections between Client location and IBM

• Firewalls

• Provisioning and Control Systems

• including maker-checker processes to ensure that unintended cross-pollination between clients cannot occur

• Security System

• Users

• Entitlements/Access

• Certificate Management

• Key Management

• Event Logging System

• Security Components

• Firewalls

• Hardware Security Manager Devices and other Key managers

• Intrusion/penetration/attack detection

• Virus and Malware detection

• Hardware trust system 

• Data Leakage

• Physical and Building Security

• Access controls and logs

• Video

• Envrironmentals - power and temperature

• Monitoring System

• Components

• Applications/Processes

• Availability

• Performance

• Reporting System

• for incident management processes

• Application

• Bank Data

• Nature of data

• Includes PII or other regulated content

• Physical geographic placement

• Geographic/movement/operative restrictions and limits

Monitoring Approach:

• parameters to be monitored

• monitoring interface to be used

• api, script, log file, etc

• normal/abnormal thresholds

• monitoring frequency

• feed to health dashboard

Reporting:

For normal situations, it is will be necessary to present a report that can be viewed by our client and its regulators.
The report content would need to be determined as would the delivery format (paper or likely a portal), and the delivery frequency (likely quarterly).

Incident Management:

For abnormal situations, an immediate reporting mechanism is needed.  
We would need to determine the following:

• Notification method:

• May include mail, phone call, text message, paper document signature delivered.

• Designated notification contacts

• Definitely the client, maybe the regulators

• Notification content

• What happened?

• Severity

• Impact

• Penetration, data loss, etc

• Forensic diagnostic data or investigation method

• Log Files

• Remediation and Corrective Actions

• For both the Cloud Service provider or the client.

• 
  

In summary...


The regulatory landscape for cloud computing is very dynamic and both cloud service providers and their clients expect these constructs to evolve.  One of the challenges will be to document these constructs in contractual documents.


Feel free to add your comments and perspectives.  I'm looking forward to a great discussion.